Decision Support System

ArgMed:A Support System for Medical Decision Making Based on the Analysis of Clinical Discussions.

Extended Abstract

The case study is about: ArgMed: A Support System for Medical Decision Making Based on the Analysis of Clinical Discussions.

Description:

Introduction

Introduction goes here

Detailed Proposed Methodologies

Detailed proposed methodology goes here …

Discussion

Discussion goes here …

Conclusion

Conclusion of the report goes here …

References

End of Report

ArgMed: A Support System for Medical Decision Making Based on the Analysis of Clinical Discussions

Malik Al Qassas, Daniela Fogli, Massimiliano Giacomin, and Giovanni Guida

Abstract This paper presents the design, development and experimentation of ArgMed, an interactive system aimed at supporting decision making processes that occur during clinical discussions. Clinical discussions take place on a regular basis in hospital wards and provide the forum for specialists of various medical disciplines to focus on critical cases, debate about diagnostic hypotheses, therapeutic protocols or follow-up of patient conditions, and to devise the most appropriate treatments. However, in the current medical practice, clinical discussions are usually not documented, and only the final decision is recorded on patient medical records. Therefore, some decision alternatives may get lost, the justifications for decisions made are not clarified, and the reasons in favor or against a diagnosis or a treatment remain implicit. ArgMed addresses these issues by supporting (1) the representation of discussions in a structured yet intuitive way, (2) the formalization of discussions from a logical perspective on the basis of a set of reasoning patterns (argumentation schemes) that are considered valid in the specific medical domain, (3) the identifica- tion of plausible conclusions, as well as invalid reasoning steps, hidden assumptions, or missing evidences. The paper describes the approach adopted for ArgMed design, the system architecture and operation, and the knowledge-based engine that implements decision support. The results of a preliminary experimentation of ArgMed in a real clinical environment are finally discussed.

2.1 Introduction

Clinical discussions concern the debates that physicians carry out when they need to face clinical cases that deserve specific attention and can not be dealt with by resorting to standard guidelines. The problems faced in a discussion may concern

M. Al Qassas • D. Fogli (�) • M. Giacomin • G. Guida University of Brescia, Brescia, Italy

e-mail:

malikq2008@yahoo.com

;

daniela.fogli@unibs.it

;

massimiliano.giacomin@unibs.it

;

giovanni.guida@unibs.it

© Springer International Publishing Switzerland 2016 15

J. Papathanasiou et al. (eds.), Real-World Decision Support Systems, Integrated Series in Information Systems 37,

DOI 10.1007/978-3-319-43916-7_2

16 M. Al Qassas et al.

diagnosis, treatment, or follow-up of patient conditions. Clinical discussions belong to a consolidated practice and generally take place once or twice a week in each specialty department of a hospital. A clinical discussion typically includes a sequence of sessions or meetings, where new cases are faced and cases already discussed in previous meetings are reconsidered, since, for example, the outcomes of new tests are available, a diagnostic hypothesis has still to be analyzed, the first effects of a treatment have to be assessed, and the treatment must be confirmed or changed.

In this paper we face the topic of clinical discussions from a practical perspective. We start from the identification of the users, we analyze their requirements, we then design and develop a system specifically tailored to meet the stated specifications, and, eventually, we experiment it in a real hospital environment.

We advocate that all the tasks physicians must face in a discussion share a common issue, namely decision making. Identifying the most likely diagnosis, selecting the best treatment, and facing possible follow-up problems timely and effectively require to take into account all information available, to apply valid reasoning patterns, and eventually to make a decision. What is needed to help physicians in these complex tasks is therefore a computer-based tool that can support their decision making processes, that is a Decision Support System (DSS).

More specifically, the DSS should support the physicians in three main tasks:

· keeping track of past discussion sessions and reviewing their main points, including the assertions made, their temporal sequence and logical relations, the decisions made, and the reasons that led to such decisions;

· establishing at each step of a discussion—or at the end of a meeting—which are the conclusions that can be logically supported by the available evidence and that might be considered as reasonable, justified decisions;

· identifying possible open problems in a discussion session, such as missing infor- mation, weak deductions not supported by enough evidence, or contradicting assertions, in order to face them in the next meeting.

Such a DSS would be not only useful, but to a large extent necessary. In fact, in the current medical practice, clinical discussions are not documented in medical records, except for the final decisions made by the medical team. As a consequence, some minor decisions may get lost as well as the justifications underlying the main decisions; the reasons in favor or against an hypothesis often remain implicit; the problems left open at the end of a meeting may be forgotten and not resumed in the next one. The impact of these issues on the quality of clinical practice should not be underestimated: it is known that inadequate medical record keeping may threaten health care quality as far as continuity of care and decision-making capabilities are concerned [23]. Moreover, the lack of documentation and logical support makes it difficult, in the unfortunate situation where a lawsuit is filed, to provide adequate justifications.

The proposed DSS, called ArgMed, is intended to be used in a hospital environment and to require only minimal training of the physicians involved. Also, it might be used by young doctors for training purposes.

2 ArgMed: A Support System for Medical Decision Making 17

In addition to facing the issue of clinical discussions from a novel perspective, ArgMed deploys new technologies. It includes three modules, namely: a Discussion Documentation Module (DDM) which is used to represent the content of a discussion session in a structured yet intuitive way, a Discussion Interpretation Module (DIM) that supports the formalization of a discussion session from a logical perspective according to a specific logical theory, and a Discussion Analysis Module (DAM), in charge of finding plausible conclusions and identifying possible logical flaws. All three modules are based on original approaches specifically designed for the clinical discussion context. DDM relies on a tree-like structure, the discussion tree, which supports a detailed representation of the assertions made during a meeting and of the temporal and logical relations among them [16]. It is strongly based on human-computer interaction methodologies [27], necessary both to support simple construction of a representation, and to allow easy understanding by all involved physicians. DIM deploys practical argumentation concepts [36], and in particular argumentation schemes [38], to represent the content of a discussion session in formal terms. Finally, DAM is based on a state-of-the-art algorithm for the computation of the justification states of a set of arguments related to a binary notion of attack [10]. As a whole, ArgMed can be classified as a knowledge-driven DSS [30], since it relies on specific domain knowledge, coded into a collection of argumentation schemes specifically designed for the medical domain, which constitutes the knowledge base of the DSS. Argumentation theory [7, 10] is adopted as the basic reasoning mechanism to process available knowledge in a decision- making framework.

ArgMed contributes to the current state of the art from several perspectives. Many Clinical Decision Support Systems (CDSSs) have been proposed to support coordination of different specialists and help them manage the huge amount of information provided by heterogeneous sources, including for example clinical guidelines and trials [34]. Other tools support the management of electronic medical records, such as WebPCR [40], LifeLines [29], and CareVis [4], and allow mon- itoring the state of patients under specific medical treatments. More sophisticated systems, such as REACT [19] or HT-DSS [14], help physicians perform complex planning activities. Finally, some CDSSs are able to suggest the decisions to make but without providing the relevant motivations [28], while others, such as CAPSULE [39], also provide justifications for the suggested decisions. However, the aim of all the above systems is to provide a direct support to collaboration and decision making, rather than tracking the reasons underlying the decisions of physicians. They often provide specific communication tools, such as email or chat, but they do not allow structuring actual discussions and pointing out the decisions emerging from them and the underlying motivations.

The problem of generating an electronic patient record that represents also a trace of the interactions occurred in the decision-making process is addressed in [23] through a form-based system and the use of a shared visual display. However, this system only supports collection and recording of structured data about a discussion, without providing any useful tool for interpretation and analysis.

18 M. Al Qassas et al.

Systems based on argumentation theory [31] have been proposed in the medical domain to help decision makers express their arguments and counterarguments, in order to solve conflicts and track the motivations underlying decisions [17]. In particular, computer-supported argumentation visualization systems aim to rep- resent arguments in a clear and simple way, by offering users an intuitive and easy-to-use interface. These systems are usually designed for a specific application domain (such as, for example, education, law, politics) and provide different kinds of diagrammatic representations of arguments, based on graphic notations proposed in argumentation theory [2, 20, 32]. Whereas the majority of such systems are aimed at driving a discussion enforcing some constraints on the participants in the debate [2, 20, 24, 35], the focus of ArgMed is on the representation and analysis of free clinical discussions and collaborative decision making.

The paper is structured as follows. Section 2.2 describes the iterative approach followed in the development of ArgMed, while Sect. 2.3 states the main functional requirements and illustrates the overall system architecture. Section 2.4 focuses on the design and implementation of the system and includes a description of its three main modules. The user interface and the interaction between ArgMed and its users are illustrated in Sect. 2.5, while Sect. 2.6 discusses the experimentation of the system carried out at The Specialty Hospital (Amman, Jordan). Finally, Sect. 2.7 concludes the paper and provides perspectives for future work.

2.2 An Iterative Approach to System Development: From Requirements Collection to Field Testing

A user-centered design (UCD) methodology has been adopted for ArgMed devel- opment [3, 26, 27]. Attention has been focused on users’ needs, characteristics, preferences and tasks, in order to develop a product able to support and improve users’ current work practice and to favor system acceptability and user satisfaction [15]. Users have been involved from the very beginning in the software development life cycle through interviews, direct observation, focus groups, and prototype evaluation.

Iterative development of prototypes is the core of UCD [9]. Each prototype is evaluated with the users and, if it does not fully meet user’s needs, the design process is iterated and goes through the revision of the specifications and the development of a new prototype. This iterative process is stopped only when user’s needs are completely met. To implement the UCD methodology, the star life cycle of Hartson and Hix [21] has been adopted. This model includes five phases, namely: task analysis, requirements specification, design, prototyping, and implementation. The development process can start from any phase, and each phase is always followed by an evaluation activity, before proceeding to the following one. This life cycle model allowed us to gradually refine the requirements, the design, and the implemented

2 ArgMed: A Support System for Medical Decision Making 19

system, on the basis of the feedback gathered from the physicians involved in clinical discussions.

More specifically, in the early phase of the project we experimented existing argumentation-based tools for discussion documentation [19, 35, 39] and we col- lected a first feedback from the physicians. After that, we analysed a real case study consisting of a 67-min video recording of a meeting provided by a multidisciplinary team working at the Department for Disabled People of an Italian hospital. This way, it was possible to observe and analyze in detail how the team members proposed their points of view, how the discussion evolved, and how a shared conclusion was reached in the end.

After this preliminary phase, we started the iterative development of ArgMed. Initially, it consisted in the design of paper-based and interactive prototypes, inter- leaved with interviews with students of the medical school and expert physicians. This activity allowed us to define a way to interactively create a discussion rep- resentation, during the discussion itself. Also, we investigated how the represented discussions could be analysed to help physicians identify weak points, missed infor- mation and possible faulty conclusions. In order to gather additional information and feedback, we examined and discussed with sample physicians some cases taken from the well-known American television medical drama “House M.D.”, which usually deals with rare pathologies and difficult diagnoses. After this phase, mostly focused on requirements analysis, the first version of ArgMed was implemented, limited to the Discussion Documentation Module. As reported in [16], an expert physician, a novice physician, and a graduate student in medicine participated in testing the first version of DDM. We then refined this module on the basis of users’ feedback and, later, the development of the Discussion Interpretation Module and of the Discussion Analysis Module started. These activities were carried out by taking into consideration several clinical discussions reported in the literature [6] as a test bench. Let us notice that the idea of organizing ArgMed in three modules emerged progressively from the iterative system development and evaluation with users. Finally, a complete version of the ArgMed prototype, developed as a web-based application, was delivered and experimented at the Specialty Hospital (Hamman, Jordan). Experimentation results are reported in Sect. 2.6.

2.3 Requirements and System Architecture

2.3.1 ArgMed Requirements

The final requirements of ArgMed, resulting at the end of the iterative process illustrated in the previous section, are summarized in Table 2.1. Requirements have been divided into four classes, one for general requirements and three for the specific modules DDM, DIM, and DAM.

20 M. Al Qassas et al.

Table 2.1 Requirements of ArgMed

General requirements

Manage a sequence of discussion sessions (meetings) about a given clinical case, taking place in a given period of time.

Support distributed access to all ArgMed data bases (discussion documentation, analysis, and feedback) by all users at any time.

Discussion Documentation Module

Support easy generation of discussion documentation in real time during a meeting or off-line.

Deploy a simple and intuitive visual representation for documenting a discussion (the assertions made, their authors, and their temporal and logical relations).

Generate a visual representation of a discussion understandable by all users. Require a minimal training effort for effective use.

Discussion Interpretation Module

Support logical interpretation of a discussion after a meeting, based on the available discussion documentation and on a collection of argumentation schemes that represent usual reasoning patterns specific of the clinical domain.

Deploy a simple formal language for representing the logical structure of a discussion through a set of arguments (instantiated argumentation schemes).

Generate a visual representation of the logical structure of a discussion understandable by all users.

Require an acceptable training effort for effective use.

Allow updating the collection of the reference argumentation schemes used to interpret a discussion (delete, modify, insert new) by domain experts supported by argumentation specialists through an

Argumentation Scheme Editor (ASE).

Discussion Analysis Module

Perform logical analysis of the logical structure of a discussion in order to identify conflicts, missing information, and acceptable conclusions.

Deploy a sound argumentation algorithm for performing discussion analysis.

Deploy a simple intuitive language for representing the results of discussion analysis. Generate a representation of the results of discussion analysis understandable by all users and presented to them at the beginning of the next meeting.

More details about the meaning and implementation of such requirements are provided in the following sections.

2.3.2 System Architecture

According to the requirements stated in the previous section, the overall architecture of ArgMed comprises three main modules as illustrated in Fig. 2.1:

· The Discussion Documentation Module supports the discussion assistant, gener- ally a young physician taking part in the meeting, in representing the content of a discussion session, namely: the assertions made, their authors, their temporal sequence, and their basic logical relations, such as conflict or support. Discussion

2 ArgMed: A Support System for Medical Decision Making 21

Fig. 2.1 Overall architecture of ArgMed

documentation may take place in real time during the meeting or, in case this is not possible for practical reasons, the discussion is recorded and documentation follows shortly after its conclusion.1 The result of this activity is a discussion tree, that shows all relevant information about a discussion in a graphical form.

· The Discussion Interpretation Module is used by a physician specifically trained to interpret a discussion tree and formalize its content in a well defined logical formalism. Interpretation is carried out after the meeting and deploys a collection of argumentation schemes that model shared reasoning patterns specific for the medical domain. The collection of argumentation schemes that will be used for discussion interpretation is created at system design time by expert physicians supported by a knowledge engineer skilled in argumentation theory; it can be updated whenever the need to refine or drop existing argumentation schemes or to add new ones arises. The result of discussion interpretation is a discussion graph that shows the arguments stated during a meeting and the support and attack relations among them.

1From the experimentation it emerged that documenting a discussion in real-time is time consuming, thus the physicians judged the second option a more viable practice.

22 M. Al Qassas et al.

· The Discussion Analysis Module is in charge of processing the discussion graph in order to generate a feedback for the physicians to be taken into consideration before the next meeting. The discussion feedback includes: (a) plausible conclusions logically coherent with the current state of the discussion together with the relevant justifications, (b) assertions excluded and the relevant motivations, (c) possible missing information that might be useful for a deeper understanding of the issues faced. The feedback is generated automatically by a justification algorithm that produces the relevant results, presented to the physicians in an easy and natural way.

The discussion tree, discussion graph and discussion feedback of each meeting are stored in a database shared by all physicians. At any moment, and especially before the start of a new meeting, physicians can access the database, review past discussions, and focus on the feedback from the last discussion. This way, ArgMed provides physicians a focused and proactive support, not only helping them remember past discussions, but also suggesting plausible decisions and singling out possible open issues to take into consideration in the next meeting.

2.4 System Design and Implementation

2.4.1 Discussion Documentation

The Discussion Documentation Module has been designed to achieve a balance between two partially conflicting requirements: on the one hand, the module should be tailored to the physicians’ habits and able to cope with a free discussion style, without constraining physicians to follow a fixed protocol or a predefined discussion scheme; on the other hand, it should support the creation of a structured representation of a discussion, in order to allow physicians to quickly recall them after some time.

The language designed for this purpose allows organizing discussion statements in a tree diagram, called discussion tree, which resembles in some way the IBIS-like notation of Rationale [33] and adopts a specific medical ontology. The types of the nodes of the discussion tree correspond to common medical concepts recurring in clinical discussions, and can be classified in two categories:

· Discussion elements, which correspond to opinions expressed by the physicians participating in the discussion. The types of discussion elements available in ArgMed are listed in Fig. 2.2 along with the icons used for their graphical repre- sentation. The name of the specialist who expressed the opinion is associated to the corresponding discussion element.

· Information elements, which represent basic information concerning the clinical case at hand and on which physicians’ opinions are based (see Fig. 2.3).

2 ArgMed: A Support System for Medical Decision Making 23

Fig. 2.2 ArgMed discussion elements and their graphical representation

Fig. 2.3 ArgMed information elements and their graphical representation

When the physician starts documenting a new discussion, the root node is generated automatically. Information elements can then be inserted by the user at any time without specific constraints, while the creation of the discussion tree is constrained by some simple composition rules that, for instance, force the user to start with a Diagnosis, a Non-pathological hypothesis or a Treatment node (for example, it is not possible to support the automatically generated node with a “Motivation PRO” node).

Any node can be connected to another node through an edge, graphically denoting that a relation holds between the two nodes. The user is not required to specify the meaning of such relation, rather the edges are simply conceived as a graphical support to recall the structure of the discussion. In particular, users are not forced to adopt terms they are not familiar with, such as “argument”, “support” or “attack”, even though they may implicitly express such relations during the construction of the discussion tree. For instance, linking a “Motivation PRO” node to a specific node indicates that the corresponding relation is a support and, conversely,

24 M. Al Qassas et al.

the use of a “Motivation CON” node implies an attack relation. The feedback of physicians gathered during system development suggested that the adoption of such nodes, instead of explicitly labelling a relation as a support or an attack, was a more natural way to represent a discussion.

An example of discussion tree is reported in Sect. 2.5.2.

Of course, several concepts may remain implicit or even ambiguous in the discussion tree. One of the aims of the DIM, described in the next section, is to provide a more structured and clear representation of the discussion from a logical point of view.

2.4.2 Discussion Interpretation

The Discussion Interpretation Module supports the process of translating the discus- sion tree produced by the DDM into a structured logical representation that adheres to a suitable formalism. The aim is to foster discussion interpretation from a logical point of view, that is identifying the basic propositions underlying natural language statements and the relationships between them. To this purpose, we exposed physicians with several argumentation-based notations and got their feedback. On the basis of the expert opinions collected, we decided to deploy argumentation schemes [37, 38] as the basic structure of our representation language, since they turned out to be easily understandable, and physicians agreed that they support the identification of possible weak points in a discussion, such as, for example, that a possible diagnosis has been neglected, that a doubt about a diagnosis or a treatment might be raised, or that some important information to support the selection of the best treatment is missing.

An argumentation scheme is a structured representation of a reasoning pattern including, according to Walton [37], a set of premises, a conclusion, and a set of critical questions. The conclusion can generally be assumed as true if all the premises are true, however critical questions can be used to challenge the validity of the relation between the premises and the conclusion, thus providing a sieve to ensure that the reasoning pattern is applied in the correct way. In particular, when at least one critical question receives a positive answer, the relation between premises and conclusion is undermined. In our system, an argumentation scheme is a structured entity including

· the name of the argumentation scheme

· a set of parameters

· the set of premises

· the conclusion

· a set of critical questions

With respect to the structure proposed in [37], we added the set of parameters, which appear in premises, conclusions and critical questions, and which support argument

2 ArgMed: A Support System for Medical Decision Making 25

creation. In other terms, assigning a value to each parameter makes it possible to instantiate the argumentation scheme to a specific case, thus yielding an argument. The set of argumentation schemes necessary to model the specific domain of clinical discussions must be identified by a knowledge acquisition activity carried out jointly by knowledge engineers and domain experts. To support this task ArgMed includes a syntax-directed editor of argumentation schemes, namely the

Argumentation Scheme Editor (ASE).

Inspired by the work of Walton [37], who introduced a comprehensive set of argumentation schemes for the legal domain, we identified a set of argumentation schemes useful to interpret clinical discussions in the medical context. To this purpose, we considered a variety of case studies, some reported in literature (for example, [11, 18, 22]) and many others found among the Case Records of the Massachusetts General Hospital [1]. In the following we report an excerpt of the argumentation schemes necessary to model discussions focusing on the identification of the best treatment for a patient. An example of the use of such argumentation schemes is reported in Sect. 2.5.3.

The Argument for Treatment Efficacy (ATE) scheme is used to model the opinion that a specific treatment would be a good choice for a patient.

ATE(P, D, T):

Parameters: P (Patient), D (disease), T (treatment). Premise 1: Patient

is affected by disease . Premise 2: Treatment is able to cure disease .

Conclusion: Treatment should be brought about for patient

.

CQ1: Is there an alternative treatment better than ?

CQ2: Is there a risk for patient

in following treatment ?

CQ3: Is there a side effect for patient

in following treatment ?

The Argument for Treatment Risk (ATR) scheme models a case where there is a risk in applying a given treatment and therefore the patient should not follow it.

ATR(P, T, N):

Parameters: P (Patient), T (treatment), N (a set of health conditions of a patient).

Premise 1: Patient

has conditions .

Premise 2: Conditions are a contraindication for treatment .

Conclusion: Patient

should not follow treatment .

CQ1: Does

have any specific condition that can limit the risk for implied by conditions ?

The Argument for Risk Containment (ARC) scheme can be used to respond to the critical question of the previous ATR scheme.

ARC(P, C1, C2, T):

Parameters: P (Patient), T (treatment), C1, C2 (characteristics of a treatment).

Premise 1: Patient

has conditions .

Premise 2: Conditions limit the risk of treatment under conditions .

Conclusion: The risk for

in following treatment is limited. CQ1: Is there an additional risk for patient

in following ? CQ2: Is there a side effect for patient

in following ?

26 M. Al Qassas et al.

The Argument for Better Treatment (ABT) scheme models the proposal of a better treatment with respect to a previously considered one.

ABT(T1, T2, C1, C2, P, D):

Parameters: P (Patient), D (disease), T1, T2 (treatments), C1, C2 (characteristics of a treatment).

Premise 1: Patient

is affected by disease .

Premise 2: Treatment with characteristics is able to cure disease . Premise 3: Treatment with characteristics is able to cure disease . Premise 4: Characteristics are preferable w.r.t .

Conclusion: Treatment should be brought about for patient

.

CQ1: Is there an alternative treatment better than ?

CQ2: Is there a risk for patient

in following ?

CQ3: Is there a side effect for patient

in following ?

The Argument for Preference from Side Effects (APSE) scheme represents a possible reason to prefer a set of treatment characteristics over another, namely that the first set does not include some side effects that are instead included in the second set.

(
f
g
)APSE(C1, C2, E1, E2,…, En ):

Parameters: C1, C2 (characteristics of a treatment), E (side effects).

Premise 1: Characteristics include side effects .

Premise 2: Side effects are not included in characteristic .

Conclusion: are preferable w.r.t .

CQ1: Are there other reasons to prefer w.r.t. ?

Finally, the personal opinion of a set of physicians can be modelled by means of the following Argument from Medical Expert Opinion (AMEO) scheme.

(
f
g
)AMEO ( PH1, PH2, PH3,. . . , DOM, A):

Parameters: PH (physicians), DOM (medical domain), A (assertion).

Premise 1: Physicians are specialists in domain .

Premise 2: Physicians assert .

Conclusion: .

CQ1: Is inconsistent with other experts’ assertions?

CQ2: Is inconsistent with recent studies?

CQ3: Is there no evidence that substantiates assertion ?

CQ4: Is the assertion not in domain ?

In order to build a logically structured representation of the reasoning activity taking place in a clinical discussion, argumentation schemes are used to interpret the assertions made by participants in a meeting. Focusing on a single fragment of a discussion at a time, the argumentation scheme that best fits the underlying reasoning path is selected and instantiated to yield an actual argument. Since each argument can be attacked or supported by others, arguments can be connected through edges that represent the relations of support or attack between them. In our approach, this can occur in two ways:

· In the instantiation phase, a relation of attack or support to other arguments can be manually defined by the user (this is the only possible way of defining support relations between arguments).

2 ArgMed: A Support System for Medical Decision Making 27

Fig. 2.4 An example of argument-relation graph for treatment-related argumentation schemes

· Attacks can be automatically derived through critical questions. More specifi- cally, after instantiating an argumentation scheme, the user can give a positive answer to a critical question. As a consequence, another argumentation scheme is automatically instantiated by the system, generating a new argument that attacks the previous one. The argumentation scheme which is automatically instantiated is selected on the basis of an argument-relation graph that can be defined through the editor of argumentation schemes. Figure 2.4 shows the argument-relation graph for the argumentation schemes related to the issue of treatment selection. Each node represents an argumentation scheme and each edge represents a relation between two argumentation schemes. An edge is labeled by a critical question associated to the first argumentation scheme and whose positive answer leads to the creation of an argument that is an instance of the second argumentation scheme. The generated argument will thus attack the previous argument, namely the instance of the first argumentation scheme. In some cases, the second node is the same argumentation scheme, meaning that an argument of the same type will be instantiated (see ABT node in the figure).

As a result of the interpretation of a discussion through instantiation of argumen- tation schemes, a discussion graph is obtained, whose nodes represent arguments and whose edges represent support or attack relations.

28 M. Al Qassas et al.

2.4.3 Discussion Analysis

The aim of the Discussion Analysis Module is to process the discussion graph so as to generate a useful feedback for the user, which can support a deep understanding of the reasoning activity carried out in the discussion.

The fundamental step to generate a suitable discussion feedback is the identi- fication of the decision set, namely the set of justified arguments that arise from the actual arguments posed in the discussion as well as the attack and support relations holding between them. The computation of justified arguments relies on argumentation theory, that represents a well-established logical reasoning paradigm to model common-sense discussions [8].

More specifically, the discussion graph can be translated into an abstract argumentation framework, namely a directed graph whose nodes correspond to arguments and whose edges represent an attack relation between them. Note that supporting arguments in the discussion graph are considered as new premises of the arguments they support; in this way, all support relations can be removed and dealt with additional attack relations. The identification of justified arguments is based on Dung’s theory [13], which is widely recognized as a fundamental reference in computational argumentation for its ability to capture a variety of more specific approaches as special cases. The concept of extension plays a key role in this setting; an extension is a set of arguments that intuitively can survive the conflict together. Several definitions of extensions have been proposed in the literature, corresponding to different argumentation semantics: the semantics deployed in ArgMed is the preferred semantics, which is widely adopted in argumentation approaches [7]. In plain terms, preferred extensions correspond to the maximal sets of arguments satisfying two constraints, namely: (1) they are conflict-free, i.e. there are no attacks between arguments belonging to an extension; and (2) they are self-defending, i.e. if an argument not belonging to an extension attacks another argument belonging to the extension, it is in turn attacked by an argument of the extension itself; that is, intuitively, for any possible objection against the point of view represented by an extension, the extension is able to provide a valid response. In ArgMed, extensions are computed by the state-of-the-art solver ArgSemSat [10], which resorts to multiple calls to a Boolean Satisfiability Problem (SAT) solver in order to identify the sets satisfying the above mentioned constraints. A filtering procedure is then applied to select the maximal ones, i.e. the preferred extensions.

The Discussion Analysis Module highlights justified arguments to the user, i.e. those belonging to all preferred extensions, since their conclusions represent the decisions that can be plausibly made on the basis of the arguments present in the discussion and on their relations.

If such conclusions differ from the discussion outcome, then there is a risk that the discussion is affected by some invalid reasoning step, for example there is a counterargument to the decision made that has not been explicitly questioned.

DAM also allows the user to explore unjustified arguments as well as the relevant counterarguments, in order to have a clear view of the reasons why their conclusions

2 ArgMed: A Support System for Medical Decision Making 29

have been discarded. Moreover, the user can explore the set of critical questions of justified arguments: this way, a physician might realize whether any of them did not receive sufficient attention in the discussion, thus identifying missing evidences that should be considered in the next meeting.

2.4.4 ArgMed Implementation

ArgMed has been implemented as a web-based client-server application, which ensures ubiquitous access from any site and user device, simply endowed with network connectivity and a web browser; furthermore, this architecture does not impose maintenance burdens or costs, since there is no need to install and maintain desktop applications. On the server side, a PHP web application has been developed, built on top of the Apache web server. On the client side, ArgMed has been implemented as a Rich Internet Application through the adoption of AJAX and the JQuery library. Data are stored within a MySQL DBMS and the JSON protocol is used for data exchange. In particular, argumentation schemes created through ASE and arguments generated by DIM are stored in a database compliant with the Argument Interchange Format (AIFdb) [12], developed by the scientific community to support the interchange of ideas and data between different projects and applications in the area of computational argumentation. Some extensions of AIFdb have been specifically implemented for the ArgMed project, in order to allow the instantiation of argumentation schemes and the definition of argument-relation graphs.

2.5 User Interaction

This section shows the user interface of ArgMed and describes the interaction of the user with the DDM, DIM and DAM modules. An example of a real clinical discussion is first introduced in Sect. 2.5.1 to be used as running example.

2.5.1 A Clinical Discussion

The discussion considered here as a running example concerns a case of appendic- ular abscess; it has been provided by the physicians participating in the experimen- tation of ArgMed at The Speciality Hospital (see Sect. 2.6). The case is reported in Table 2.2. It involves a team of surgeons, namely a chief surgeon (S1) and some seniors, juniors, and students in general surgery (S2,..,S5), who discuss about finding the best treatment to apply to a young patient with an appendicular abscess. The discussion starts with the presentation of the case and develops with each

30 M. Al Qassas et al.

Table 2.2 The appendicular abscess case

Presentation of the case

A 7 year old male complaining of abdominal pain and fever for the past 5 days. He is also complaining of recurrent vomiting. The abdominal pain is diffuse lower abdominal pain and is associated with diarrhea. Patient report and physical examination is compatible with complicated appendicitis. Ultrasound and CT-scan show an appendicular inflammatory mass and small fluid collection 3*3 cm in the right iliac fossa. WBC (white blood cell count): 17,000 and temperature: 38.9. Vital signs are within normal range (Blood pressure, Heart rate, respiratory rate).

First meeting

S1,A1: My opinion is to drain the fluid collection and treat with IV antibiotics. This has a good cure rate and the patient will remain stable.

S2,A2: I agree with S1, this treatment has a good cure rate.

S3,A3: From our past experience, we have always performed this treatment, so I agree with S1 and my preference is to do the same.

S4,A4: It’s only been 5 days since symptoms started, I believe the mass is not well formed (from ultrasound and CT-scan), and the appendix can be easily excised and we’ll shorten the patients hospital stay.

S5,A5: I agree with S4, the appendix can easily be excised and we’ll shorten the patients hospital stay.

S1,A6: An operation would be risky with an appendicular mass. But you don’t need to do an interval appendectomy and the fluid collection is too small to be drained; we can cover with antibiotics and wait.

S4,A7: I believe that we have to repeat the ultrasound and CT-scan to better analyze the size of inflammatory mass and the fluid collection, and then decide the most appropriate treatment for this case.

S1,A8: I agree with S4.

S5,A9: I agree with S4, It’s better if we repeat the examinations.

Second meeting

S1,A10: From the ultrasound and the CT-scan we have the same result (a small appendicular inflammatory mass and a small fluid collection 3*3 cm in the right iliac fossa), so my opinion is to treat with IV antibiotics without the drainage of the fluid collection.

S2,A11: I agree with S1, an operation would be risky to a child patient with an appendicular mass.

S5,A12: I agree with S1, there are new medical studies reporting that if we treat with IV antibiotics, we will have a good cure rate.

Final decision

Treat the patient with IV antibiotics if he remains stable. Consult the patient that 10 % will recur as simple acute appendicitis and they can be treated accordingly.

participant proposing his/her opinion about how to cure the patient. In the first session of the discussion, the surgeons decide to repeat some examinations (see statement A9 in Table 2.2) and in the next session they decide the best treatment for the patient (antibiotics). The next sub-sections illustrate ArgMed user interface and operation with the help of a portion of this discussion.

2 ArgMed: A Support System for Medical Decision Making 31

2.5.2 Discussion Documentation

Figure 2.5 shows a screenshot of the Discussion Documentation Module. The central area is organized according to a tab-based structure: in the first tab, called “Discussion”, the user can compose the discussion tree. To this end, the user can drag-and-drop the discussion elements available in the left area, thus creating a diagnosis, a treatment, a non-pathological hypothesis, an examination request, or a motivation in favour (pro) or against (con), i.e. an explicit assertion that corroborates or contradicts a given statement. The user can also access information elements (Personal Data, Symptoms, Semeiotics, Anamnesis, Direct Observations, Examination Reports) available in the other tabs and select them to be included in the discussion tree as nodes in favor or against other nodes of the discussion.

In particular, in Fig. 2.5 the Discussion tab includes a representation of the first four statements of the sample case study. A treatment node corresponding to statement A1 “My opinion is to drain the fluid collection and treat with IV antibiotics. This has a good cure rate and the patient will remain stable” has been created and connected to the root of the discussion tree. Then, statements A2 and A3, which provide motivations for supporting statement A1, have been associated with two Motivation PRO nodes connected to the treatment node. Statement A4 “It’s only been 5 days since symptoms started, I believe the mass is not well formed (from ultrasound and CT-scan), and the appendix can be easily excised and we’ll

Fig. 2.5 The discussion tree representing the first four statements of the appendicular abscess case

32 M. Al Qassas et al.

shorten the patients hospital stay” proposes an alternative treatment with respect to that indicated in statement A1. Therefore, since statement A4 actually attacks A1, a new Motivation CON node has been created and connected to the node A1.

2.5.3 Discussion Interpretation

After a discussion has been carefully documented, the user can formalize its content through the Documentation Interpretation Module. Figure 2.6 shows a screenshot of this module, where the discussion statements are visualized as a multi-level list in the left part of the screen. The user may select these statements and create a set of arguments related to the discussion by instantiating suitable argumentation schemes. In Fig. 2.6, the user is creating a new argument associated with statement A1.

On user request to create a new argument, the system asks him/her the argument name and the type of argument (that is the argumentation scheme that must be instantiated). Moreover, if the argument has to be connected to another argument, the user can indicate the later argument and the relation type (attack, support or neutral) of the connection. For statement A1, the user has inserted “Arg1” as argument name and has selected ATE (“Argument from Treatment Efficacy”) among the available argumentation schemes and “Neutral” as relation type, since it is the first argument created for this discussion. The user can edit the argument parameters by clicking on the words in bold to activate a pop-up allowing parameter value setting (see Fig. 2.6). Figure 2.7 shows the elements of argument Arg1 with the parameters edited by the user. Here, the user has assigned the parameter “Disease” the value “appendicular abscess” and the parameter “Treatment” the value “drainage and antibiotics”.

Fig. 2.6 The user is editing one parameter of “Arg1” created for the statement A1

2 ArgMed: A Support System for Medical Decision Making 33

Fig. 2.7 Arg1 as a instantiation of argumentation scheme “Argument from Treatment Efficacy”

(
D
D
) (
D
)The argumentation scheme AMEO (“Argument from Medical Expert Opinion”) can be used to represent statements A2 “I agree with S1, this treatment has a good cure rate” and A3 “From our past experience, we have always performed this treat- ment, so I agree with S1 and my preference is to do the same”. This way argument Arg2 is created and a relation of “Pro” type with argument Arg1 is defined. For this argument, the user may instantiate the parameters as follows: “Physicians” “{S2, S3}”, “Domain” “surgery”, “Assertion” “drainage and antibiotics are able to cure the appendicular abscess”.

Statement A4 “It’s only been 5 days since symptoms started, I believe the mass is not well formed (from ultrasound and CT-scan) and the appendix can easily be excised and we’ll shorten the patients hospital stay” provides an answer to critical question CQ1 “Is there an alternative treatment better than drainage and antibiotics?” of Arg1. When CQ1 of Arg1 receives a positive answer, the system, on the basis of the argument-relation graph (Fig. 2.4), instantiates the argumentation scheme ABT (“Argument for Better Treatment”), giving rise to a new argument (Arg3), which attacks argument Arg1.

The other statements of the discussion can be interpreted by the user in a similar way, by eventually generating the discussion graph.

2.5.4 Discussion Analysis

Figure 2.8 shows a screenshot of the Discussion Analysis Module. In the left area the discussion graph for the appendicular abscess case is shown. The graph has

34 M. Al Qassas et al.

Fig. 2.8 The analysis result of the Appendicular Abscess case: discussion graph (left) and decision set (right)

then been processed through the ArgSemSat solver, and the decision set has been identified including the arguments that can be considered as justified (see Fig. 2.8, right area). Here, arguments Arg2, Arg4, Arg5, Arg6, Arg7, Arg8 and Arg9 are justified.

(
C
)By clicking on the “ ” button under each argument name, the user can view the details of the argument. The user can also filter the decisions by configuration type: for example, by selecting “treatment”, only the conclusions related to treatments are shown. In this case, according to the relevant conclusions (in particular, those of Arg5 and Arg7), “antibiotics” should be brought about among the considered treatments. This corresponds to the outcome of the discussion, confirming that all possible counterarguments explicitly advanced in the discussion have been properly considered.

Of course, analysing the critical questions and how they have been tackled in the discussion, the user may always realize that alternative options did not receive proper consideration in the discussion, thus they should be examined in the next meeting.

2.6 ArgMed Experimentation

Experimentation of ArgMed was carried in July-August 2015 at the Specialty Hospital, a leading private teaching hospital, located in Amman (Jordan).

Experimentation consisted of four activities:

· indirect functional assessment through observation of multi-disciplinary meet- ings;

· direct user tests, carried out by selected physicians;

2 ArgMed: A Support System for Medical Decision Making 35

· structured after-test interviews;

· elaboration of new case studies provided by selected physicians.

Before carrying out direct user tests, the overall adequacy of ArgMed to support documentation, interpretation and analysis of clinical discussions was verified through a non-intrusive observation technique. To this purpose, one of the authors of this paper participated in 15 multi-disciplinary meetings to observe physicians’ work and assess strong and weak points of ArgMed. At Specialty Hospital, physicians regularly meet every morning (5 times/week) and discuss 3 to 5 cases in each meeting. The participants in this meeting are a chief physician (more than 15 years of experience), senior physicians (3–5 years of experience), junior physicians (1–3 years of experience), interns and students. The observation activity allowed us to get a deeper understanding of the structure of clinical discussions, of the way they developed, and of the process that led to final decision making. As a result, a first validation of the main functions offered by ArgMed and of its overall mode of operation was obtained.

Then, a senior surgeon, a junior surgeon and a junior internist participated in direct test sessions with ArgMed. After a brief presentation of the tool, physicians were trained in the use of ArgMed through the analysis of simple cases. A literature case study [11] about the treatment of larynx cancer was presented to them to be used as a test case. After that, two test sessions took place. In the first session users were asked to carry out specific tasks, such as representing a few assertions through the documentation language, interpreting assertions through available argumentation schemes, and launching the analysis step. In the second session, users were required to autonomously create, document and analyze a substantial fragment of the discussion about the treatment of larynx cancer.

In both test sessions, a thinking-aloud observation protocol was adopted to collect as much as possible feedback from the users, including reasoning strategies, the way of interacting with the system, the problems met, and any kind of comments and suggestions.

In the first test session physicians showed a positive attitude towards the system and a critical approach to task execution. The observer clarified that there were several ways to model a discussion and that each physician could make his/her choices, obviously without changing the discussion logic. The users appreciated the drag-and-drop interaction with the Discussion Documentation Module that allowed them to create the discussion tree in an easy and natural way. All of them pointed out instead the need for further training in the use of argumentation schemes, which turned out to be rather demanding.

The second test session, held after administration of a supplementary training, has been useful to investigate a more realistic use of the system. Physicians were able to easily create both the discussion tree and the discussion graph and to carry out discussion analysis to obtain a decision suggestion. The decision proposed by the system was considered plausible and useful.

36 M. Al Qassas et al.

After user tests, a structured interview was carried out with each participant to gather a more formal feedback about the usefulness and usability of ArgMed. The interview consisted of two groups of questions:

1. Usefulness

(a) Who is the ideal user of ArgMed (chief, seniors, juniors, interns, students)?

(b) How could ArgMed be integrated in the current work practice? (real-time, off-line)

(c) Do you think that critical questions are a useful tool for focusing attention on important issues and keeping the discussion on a sound logical track?

(d) Which advantages do you see in the adoption of ArgMed for discussion documentation?

(e) Which advantages do you see in the adoption of ArgMed for discussion analysis?

(f) Which drawbacks do you see in the adoption of ArgMed for discussion documentation?

(g) Which drawbacks do you see in the adoption of ArgMed for discussion analysis?

(h) Have you suggestions about additional or alternative argumentation schemes?

2. Usability

(a) Do you think discussion visualization as a discussion tree is clear and easy to understand for all participants in a clinical discussion?

(b) Is the discussion graph suitable for identifying the global logical structure of a discussion and for justifying the suggested conclusion?

(c) Do you think that ArgMed is easy to learn?

(d) Do you judge ArgMed as an efficient or time-consuming tool?

(e) Have you practical suggestions about how to improve the tool?

Table 2.3 shows the results of these structured interviews. As one can notice, par- ticipants provided very positive assessments, yet suggesting several improvements. Important remarks were made about the integration of ArgMed with the current clinical practice: in particular, participants suggested that the tool could be used after the meetings (off-line), to remember discussion details and record analyses of several discussions for future reference. ArgMed was judged very useful for consultation physicians (namely, specialists who cannot participate in the meetings), who could review the discussion off-line and insert their opinions. All interviewees highlighted the high potential of the system as an educational tool, to train students and junior physicians in clinical case analysis.

All interviewees agreed that the discussion tree was a good representation of clinical discussions, even though participants highlighted that creating such tree may be time-consuming, especially if the system is used for real-time documentation. The discussion graph was also considered very useful for identifying possible missing information, for analyzing contrasting points of view, and for focusing the final decision of a discussion.

2 ArgMed: A Support System for Medical Decision Making 37

Table 2.3 The results of the structured interviews

Off-line

Off-line

Yes

Yes

Yes

Yes

Time-consuming

Time-consuming

Senior surgeon	Junior surgeon	Junior internist
1.a	Juniors followed by seniors	Students in training followed by seniors	Interns and students
1.b			Off-line
1.c					Yes
1.d	Useful as reference for future discussions and similar cases, reduce paper usage and can be used as educational tool	Useful as reference for future cases and for training purposes	Useful for teaching purposes and as patient records for future references
1.e	Useful for training purposes	Useful as reference for future discussion analyses, useful for consultation requests, useful for training	Useful to take better decisions; useful in particular for interns and students in training
1.f	It is time-consuming if used at real-time	Creating the discussion tree is time-consuming	The discussion should be documented after the meeting is closed, thus some paper notes or video recording are needed
1.g	It does not consider the role levels of users	It does not manage the credibility of users	It does not manage the mistakes of users
1.h	Argument from history, Argument from consultation , Argument from physical examinations, Argument from laboratory examination	Argument from complications, Argument from history, Argument from vital signs, Argument from consultation	Argument from consultation
2.a	Yes, it is very effective
2.b	Yes, it is useful for analyzing contrasting opinions	Yes, but interaction with nodes must be made more intuitive	Yes, it allows focusing the final decision
2.c	Discussion documentation is easy to learn, but discussion interpretation and analysis require an expert in argumentation	Analysis requires some training in argumentation theory	Discussion documentation is easy to learn, interpretation through argumentation schemes needs several training sessions
2.d			Time-consuming
2.e	Add a search engine for clinical case retrieval, create a tablet-oriented version	Integrate protocols and guidelines, create a large database of discussions	Add option to print the discussion with suggested decisions as a PDF file

38 M. Al Qassas et al.

Participants said they found the argumentation schemes easy to learn and ade- quate to clinical discussion analysis. They also proposed some new argumentation schemes to be added to the initial set available in ArgMed, useful for a more detailed logical interpretation of clinical discussions. Furthermore, they noted that ArgMed did not take into consideration the different roles and experience of participants in a discussion, as well as their credibility. They then suggested to include in ArgMed standard clinical guidelines and local medical protocols in order to take them into account during a discussion and to assess the compliance of the final decisions made. Finally, some practical suggestions were proposed to improve the tool, such as: creating a tablet-oriented version, adding an option to print a discussion and all related materials as a PDF file, creating a structured database of the discussions held, designing a search engine for clinical case retrieval.

In the fourth experimentation activity, the physicians provided us with three further case studies involving discussions they encountered in recent meetings they attended. We elaborated with them such discussions in order to evaluate once again whether ArgMed was suitable and useful for discussion documentation and interpretation, as well as a support tool for decision making. Even though we discovered that some additional argumentation schemes needed to be included in the system, the functions available in ArgMed allowed managing successfully all the three case studies. As a consequence, we chose one of them, the appendicular abscess case, as running example for the present paper.

2.7 Conclusions

In this chapter we have presented a CDSS aimed at supporting a consolidated practice of hospitals and other healthcare facilities, that is, multidisciplinary team meetings that occur regularly once or twice per week to discuss the most serious clinical cases [22]. To our knowledge, CDSSs with a similar goal have not been proposed yet, even though their importance has been recently underlined in literature [25]. Indeed, as far as multidisciplinary team meetings are concerned, literature works address the problem from a different perspective: they are mainly aimed at facilitating the interaction among physicians through the use of advanced multimedia technologies (see for instance [18]), rather than supporting their deci- sion making tasks.

Furthermore, ArgMed supports clinical decision making in an original way with respect to traditional CDSSs. The latter are usually based on knowledge about diagnoses or treatments for specific diseases or about protocols to be followed in specific situations. ArgMed, instead, is based on higher-level knowledge about physicians’ reasoning patterns. We collected and distilled this knowledge from observations of real clinical discussions, interviews with physicians, and analysis of several clinical cases reported in literature. Such knowledge, represented as a set of argumentation schemes, is used in ArgMed for discussion interpretation and analysis, in order to provide suggestions about the decision to make or to shed

2 ArgMed: A Support System for Medical Decision Making 39

light on weak points in reasoning paths. More precisely, at the end of discussion analysis, the system is able to provide physicians with different kinds of support:

(a) suggestions for decision making, in the case only one argument related to a specific diagnosis or treatment is justified; (b) warnings about possible alternative conclusions, whenever several arguments associated to alternative diagnoses or treatments are equally justified; (c) suggestions for considering the critical questions that have remained unanswered, in order to make hidden assumptions explicit or to gather additional information about the case under discussion.

From a more general perspective, ArgMed may plays three different functions in real clinical settings [5]. First, it may play the function of “memory”, since it allows creating orderly records of all the statements made by physicians, as well as keeping trace of their temporal and logical articulation. Physicians can hardly remind the details of previous discussions and can greatly benefit from the availability of a system that helps avoid returning again on issues that have been already solved in past meetings, and prevent incurring into inconsistencies or contradictions. Second, it may sustain “reflection”, because once a discussion has been represented as a discussion tree, it can be interpreted and analysed to perform automated reasoning activities, including the identification of possible contradictions and the discovery of invalid reasoning paths (missing reasoning steps, hidden assumptions, missing evidences, etc.). The results of this analysis can support a more correct and logically sound evolution of their reasoning in the following working sessions. Third, a “generalization” activity can be performed with ArgMed: indeed, at the end of the decision making process, it is possible to reconsider the whole series of discussions held, the decisions made and their practical effects, in order to derive a best practice of general validity, which might be adopted in similar cases. This important function may not only help physicians define improved decision procedures, but may also constitute the core function of an education tool for clinical case analysis, which can be used for a more effective and focused training of young physicians.

Promising directions for future research include four main issues:

· the design of more effective and user-oriented tools to present discussion feedback; this is indeed an important point to support the practical use and the effectiveness of ArgMed;

· the extension, refinement and validation of the collection of argumentation schemes available for discussion interpretation; the elicitation of the common reasoning paths used by physicians is not an easy task and the quality of the argumentation schemes has a strong impact both on the interpretation of a discussion and on the results of the analysis;

· the comparison of the decisions made in a discussion with the relevant clinical guideline, either to correct the conclusions reached or to improve the guideline;

· the discovery from the argumentation process of new clinical knowledge to be reused in similar cases that might arise in the future.

40 M. Al Qassas et al.

References

1. Rosenberg, E.S., Harris, N.L. (eds.): Case records of the Massachusetts general hospital. N. Engl. J. Med. (2016). doi:10.1056/ NEJMcpc1415172

2. Compendium web site.

http://compendium.open.ac.uk/index.html

(2012)

3. Abras, C., Maloney-Krichmar, D., Preece, J.: User-Centered Design. Sage, Thousand Oaks (2004)

4. Aigner, W., Miksch, S.: CareVis: integrated visualization of computerized protocols and temporal patient data. Artif. Intell. Med. 37(3), 203–218 (2006)

5. Al Qassas, M., Fogli, D., Giacomin, M., Guida, G.: Supporting medical decision making through the analysis of clinical discussions. In: Phillips-Wren, G., Carlsson, S., Respicio, A., Brezillon, P. (eds.) DSS 2.0 – Supporting Decision Making with New Technologies, pp. 42–53. IOS Press, Paris (2014)

6. Al Qassas, M., Fogli, D., Giacomin, M., Guida, G.: Analysis of clinical discussions based on argumentation schemes. Procedia Comput. Sci. 64, 282–289 (2015)

7. Baroni, P., Caminada, M., Giacomin, M.: An introduction to argumentation semantics. Knowl. Eng. Rev. 26(4), 365–410 (2011)

8. Bench-Capon, T., Dunne, P.E.: Argumentation in artificial intelligence. Artif. Intell. 171(10– 15), 619–641 (2007)

9. Bødker, S., Grønbæk, K.: Cooperative prototyping: users and designers in mutual activity, pp. 331–358. Academic, London (1991)

10. Cerutti, F., Dunne, P.E., Giacomin, M., Vallati, M.: Computing preferred extensions in abstract argumentation: a SAT-based approach. In: TAFA 2013. Lecture Notes in Computer Science, vol. 8306, pp. 176–193. Springer, Berlin, Heidelberg (2014)

11. Chang, C.F., Miller, A., Ghose, A.: Mixed-initiative argumentation: group decision support in medicine. In: Electronic Healthcare – Second International ICST Conference, eHealth 2009, Istanbul, Turkey, 23–25 September, Revised Selected Papers, pp. 43–50 (2009)

12. Chesñevar, C., McGinnis, J., Modgil, S., Rahwan, I., Reed, C., Simari, G., South, M., Vreeswijk, G., Willmott, S.: Towards an argument interchange format. Knowl. Eng. Rev. 21(4), 293–316 (2006)

13. Dung, P.M.: On the acceptability of arguments and its fundamental role in nonmonotonic reasoning, logic programming, and n-Person games. Artif. Intell. 77(2), 321–357 (1995)

14. Fogli, D., Guida, G.: Enabling collaboration in emergency management through a knowledge- based decision support system. In: Respicio, A., Burstein, F. (eds.) Fusing Decision Support Systems into the Fabric of the Context, pp. 291–302. IOS Press, Amsterdam (2012)

15. Fogli, D., Guida, G.: Knowledge-centered design of decision support systems for emergency management. Decis. Support Syst. 55, 336–347 (2013)

16. Fogli, D., Giacomin, M., Stocco, F., Vivenzi, F.: Supporting medical discussions through an argumentation-based tool. In: Proceedings of the Biannual Conference of the Italian Chapter of SIGCHI (CHItaly2013), pp. 18:1–18:10. ACM Press, New York (2013)

17. Fox, J., Glasspool, D.W., Grecu, D., Modgil, S., South, M., Patkar, V.: Argumentation-based inference and decision making – a medical perspective. IEEE Intell. Syst. 6(22), 34–41 (2007)

18. Frykholm, O., Groth, K.: References to personal experiences and scientific evidence during medical multi-disciplinary team meetings. Behav. Inform. Technol. 30(4), 455–466 (2011)

19. Glasspool, D.W., Oettinger, A., Smith-Spark, J.H., Castillo, F.D., Monaghan, V.E.L., Fox, J.: Supporting medical planning by mitigating cognitive load. Methods Inf. Med. 46(6), 636–640 (2007)

20. Gordon, T.F.: An overview of the carneades argumentation support system. In: Reed, C., Tindale, C.W. (eds.) Dialectis, Dialogue and Argumentation: An Examination of Douglas Walton’s Theories of Reasoning, pp. 145–156. College Publications, London (2010)

21. Hartson, H.R., Hix, D.: Human-computer interface development: concepts and systems for its management. ACM Comput. Surv. 21(1), 5–92 (1989)

2 ArgMed: A Support System for Medical Decision Making 41

22. Kane, B., Luz, S.: Achieving diagnosis by consensus. Comput. Supported Coop. Work 18(4), 357–392 (2009)

23. Kane, B.T., Toussaint, P.J., Luz, S.: Shared decision making needs a communication record. In: Proceedings of the 16th ACM Conference on Computer Supported Cooperative Work (CSCW ’13), pp. 79–90. ACM Press, New York (2013)

24. Karamanou, A., Loutas, N., Tarabanis, K.A.: ArgVis: structuring political deliberations using innovative visualization technologies. In: Tambouris, E., Macintosh, A., de Bruijn, H. (eds.) Proceedings of Electronic Participation, Third IFIP WG 8.5 Int. Conf. ePart 2001. Lecture Notes in Computer Science, vol. 6847, pp. 87–98. Springer, Delft (2011)

25. Luz, S., Kane, B.: Perspectives on intelligent systems support for multidisciplinary medical teams. In: AAAI Spring Symposium Series, pp. 272–275. Springer, Berlin (2016)

26. Moran, T.P.: Design Rationale: Concepts, Techniques, and Use. L. Erlbaum Associates Inc., Hillsdale, NJ (1996)

27. Norman, D.A., Draper, S.W.: User-Centered System Design: New perspectives on Human- Computer Interaction. Lawrence Erlbaum Associates, Hillsdale, NJ (1986)

28. Peleg, M., Wang, D., Fodor, A., Keren, S., Karnieli, E.: Adaptation of practice guidelines for clinical decision support: a case study of diabetic foot care. In: Proceedings Biennal European Conference on Artificial Intelligence (ECAI). Riva del Garda, Italy (2006)

29. Plaisant, C., Mushlin, R., Snyder, A., Li, J., Heller, D., Shneiderman, B.: LifeLines: using visualization to enhance navigation and analysis of patient records. In: Proceedings American Medical Informatic Association Annual Fall Symposium, Orlando, USA, pp. 76–80 (1998)

30. Power, D.J.: Computerized decision support case study research: concepts and suggestions. In: Real-World Decision Support Systems Cases Studies. Information Management. Springer, Berlin (2016)

31. Prakken, H., Vreeswijk, G.: Logics for defeasible argumentation. In: Gabbay, D., Guenthner,

F. (eds.) Handbook of Philosophical Logic, pp. 219–318. Kluwer Academic, Dordrecht (2002)

32. Reed, C.A., Rowe, G.W.A.: Araucaria: software for argument analysis, diagramming and representation. Int. J. AI Tools 13(4), 961–980 (2004)

33. Sbarski, P., van Gelder, T., Marriott, K., Prager, D., Bulka, A.: Visualizing argument structure. In: Bebis, G. et al. (ed.) Proceedings of the Fourth Int’l Symposium Advances in Visual Computing (ISCV ’08). Lecture Notes in Computer Science, vol. 5358, pp. 129–138 (2008)

34. Sullivan, F., Wyatt, J.C.: How decision support tools help define clinical problems. Br. Med. J.

331(7520), 831–833 (2005)

35. Tolchinsky, P., Cortés, U., Modgil, S., Caballero, F., López-Navidad, A.: Increasing human- organ transplant availability: argumentation-based agent deliberation. IEEE Intell. Syst. 21(6), 30–37 (2006)

36. Van Eemeren, F.H., Grootendorst, R., Snoeck Henkemans, F.: Fundamentals of Argumentation Theory: A Handbook of Historical Background and Contemporary Developments. Lawrence Erlbaum Associates, Mahwah, NJ (1996)

37. Walton, D.: Argumentation Schemes for Presumptive Reasoning. Lawrence Erlbaum Asso- ciates, Mahwah, NJ (2006)

38. Walton, D., Reed, C., Macagno, F.: Argumentation Schemes. Cambridge University Press, Cambridge (2008)

39. Walton, R., Gierl, C., Yudkin, P., Mistry, H., Vessey, M.P., Fox, J.: Evaluation of computer support for prescribing (CAPSULE) using simulated cases. Br. Med. J. 315, 791–795 (1997)

40. Web browser based patient care report.

http://emsfiresoftware.com/products/wpcr/

(2004)