Designing a treatment path for a patient suffering from multiple conditions involves merging and applying multiple clinical guidelines and is recognised as a difficult task. This is especially relevant in the treatment of patients with multiple chronic diseases, such as chronic obstructive pulmonary disease, because of the high risk of any treatment change having potentially lethal exacerbations. Clinical guidelines are typically designed to assist a clinician in treating a single condition with no general method for integrating them. Additionally, guidelines for different conditions may contain mutually conflicting recommendations with certain actions potentially leading to adverse effects. Finally, individual patient preferences need to be respected when making decisions. In this work we present a description of an integrated framework and a system to execute conflicting clinical guideline recommendations by taking into account patient specific information and preferences of various parties. Overall, our framework combines a patient's electronic health record data with clinical guideline representation to obtain personalised recommendations, uses computational argumentation techniques to resolve conflicts among recommendations while respecting preferences of various parties involved, if any, and yields conflict-free recommendations that are inspectable and explainable. The system implementing our framework will allow for continuous learning by taking feedback from the decision makers and integrating it within its pipeline.
The Learning Health System (LHS), as defined by the US
Institute of Medicine is a term that describes a
systemwide approach to research and knowledge translation based
on the exploitation of routinely collected data
One significant component of any LHS is medical decision making and the possibilities of giving it automated support. In practice, medical decision making is often supported by clinical guidelines. These are lengthy documents summarising state-of-the-art knowledge about a medical condition and specifically its management. Clinical guidelines provide best practice recommendations to clinicians for taking care of patients under broad circumstances, mostly in the context of a single condition or a disease. Guidelines describe management of a generic patient, recommending multiple possible options for a clinician to opt for, depending on the specific circumstances. Such specific circumstances influencing the decision may amount not only to particularities regarding the disease in question, but also the presence of other diseases, i.e. the so called multimorbidity setting.
Multimorbidity (or comorbidity) is especially relevant in
the context of chronic diseases, such as diabetes, asthma,
chronic obstructive pulmonary disease (COPD), chronic
kidney disease (CKD), to name a few. They are in some
combination very often present for continuous periods of
time, usually until death, especially in elderly patients.
Furthermore, chronic diseases very often interact with each
other in that managing one has positive and/or negatives
effects on the others
Considering multiple guidelines very likely entails the
existence of interacting recommendations: the
recommendations may be inapplicable, may suggest incompatible actions
or imply conflicting effects, may overlap, and so forth. A
clinician may find it very difficult to follow the best
practices should they stem from conflicting assumptions and/or
lead to negative effects with respect to one or another
condition. In order to facilitate the clinician’s job, knowledge
representation methods are useful in representing clinical
guidelines and their interactions. However, whereas models
for representing guidelines abound, see e.g.
TMR allows for representing and merging multiple
guidelines while taking into account their interactions. In the
context of multimorbidities especially, TMR is very useful for
identifying components and relations, such as clinical care
actions, their positive and negative effects with respect to
various conditions, as well as various measures of the
quality of evidence and obligatoriness of recommendations. To
capture interactions when merging guidelines,
Automated reasoning with clinical guideline
representations and patient information, especially in the presence of
guideline interactions, is an open problem in general
Generally speaking, argumentation is a branch of
knowledge representation and reasoning concerned with reasoning
with partial and conflicting information in a way that aims
to emulate human reasoning. In medical reasoning
particularly, “argumentation is appealing as it allows for important
conflicts to be highlighted and analysed and unimportant
conflicts to be suppressed.”
To enable this, we map TMR to the ABA+ representation based on rules and arguable elements, called assumptions. This framework is instantiated using information extracted from computation representations of guidelines held in software that realises TMR. We also augment the representation in ABA+ with patient specific conditions obtained from their electronic health record (EHR). This information allows us to construct arguments (as rule-based deductions) for actions based on recommendations. We also allow for the representation of preferences over assumptions, which influence how arguments and counterarguments interact (in argumentation jargon, attack each other). We then employ extension-based argumentation semantics to execute the reasoning and obtain the acceptable assumptions as well as arguments and conclusions. The reasoning outcomes are explainable through inspection of the explicitly given assumptions, rules, preferences as well as the resulting arguments and their relationships.
To illustrate our methodology, we focus on the interaction of conflicting recommendations. As an example, we consider an artificial case study of COPD, vetted by COPD experts. In the use case, a clinician deals with a patient that presents COPD and a mild Angina. The relevant clinical guidelines recommend several actions to take or avoid. We complement the recommendations with patient information from EHR and illustrate reasoning with and without preferences. We briefly discuss why the reasoning outcomes provided by ABA+ are interpretable and explainable, and also discuss how the clinician can interact with a decision support system encompassing the ABA+-driven reasoning engine.
This paper presents work in progress. Several parts of our LHS are in place, others are being researched and implemented. With this paper we aim to give a flavour of various parts and how they can come together to support an LHS.
The paper is structured thus. In Section 2 we give preliminaries about the TMR model, its implementation and integration with EHR data, as well as background on ABA+. In Section 3 we advance a method for automated reasoning with guideline recommendations and patient information in ABA+. We illustrate our approach with a COPD use case in Section 4. We discuss related work in Section 5 and conclude in Section 6.
2
2.1
In this section we review the Transition-based Medical
Recommendation model (TMR) together with clinical guideline
recommendation interaction description as a knowledge
representation model. As in
Figure 1 depicts an instance of a graphical schema for representing recommendations in TMR. It consists of the following components.
Unique name at the top of a rounded box. For instance, R1, R2. (We write Rk instead of Rk.) Henceforth, we refer to a recommendation by its name. Associated action A within the ellipse at the top. For instance, Adm. NSAID, Adm. Aspirin, where Adm. stands for Administer.
Deontic strength indicated on the thick labelled arrow going out of the recommendation’s name and into the action.
For recommendation R, we denote its deontic strength by
d (R). It “reflects a degree of obligatoriness expected for
that recommendation”
As in
Properties that the action affects, just below the action. For instance, Blood Coag. and Gastro. Bleeding. (We abbreviate words: e.g. Gastro. Bleeding abbreviates Gastrointestinal Bleeding.) In general, an action can affect more than one property P. Effects of the actions within the dashed rectangles to the left of the properties. For instance, decrease and increase. An action A has one effect E on the property P it affects. Effects may have determinate initial and final values, within the rectangular boxes below the property in question, the black arrow coming out of the initial value (box) and leading into the final value (box). Otherwise, ? represents an indeterminate value.
For instance, action Adm. NSAID affects Blood Coag. by decreasing it from the initial value normal to the final value low. On the other hand, Adm. Aspirin increases Gastro. Bleeding with indeterminate values.
In this paper we will not make use of, but mention for completeness, two quantitative values associated with an effect. One is the causation probability within the dashed ellipse below the property. It represents the likelihood of the action bringing the effect about. For instance, often. The other one is the belief strength boxed to the left- or right-most side. It represents the level of evidence regarding bringing the effect about. For instance, normal level. Contributions of the recommendation to the overall goals in the context of a guideline indicated below the recommendation name within a transparent dashed rounded box. For instance, +C1:1, C2:1.
In general, recommendation R can have more than one contribution. Each contribution carries an identifier, e.g. C1:1, C2:1, and is valued in [ 1; 1], depending on how important it is to achieve or avoid the corresponding effect. The value is discretised with signs: +, and the absence of a sign represent, respectively, values greater than, less than and equal to 0.
As in
We will use R to denote a fixed but otherwise arbitrary set of recommendations.
Observe that an instance of TMR concerns a generic patient. In order to apply recommendations, one needs to consider specific patient conditions. Such conditions pertain to properties and the initial values of the effects that actions have on properties. For instance, a patient can have normal Blood Coag. or Gastro. Bleeding. When using ABA+ to reason with guidelines, patient conditions will come as information additional to TMR instances.
Using TMR,
The implementation of TMR used will allow for all such interactions. However, for the purpose of illustrating reasoning with recommendations using argumentation, we focus on the contradiction interaction in this paper, because it relates recommendations in direct conflict that can be naturally resolved by means of argumentation.
Formally, interactions can be represented as triples
(R; R0; m ) with recommendations R and R0, and the
interaction’s modal strength m , which reflects the conclusiveness
of the interaction. The interaction’s modal strength can take
two values, denoted by and , where means “the
interaction will certainly occur if the related recommendations
are prescribed”
Note well that R and I amount only to representation of guidelines, but not reasoning with them. In particular, it is a patient-agnostic representation, while the reasoning happens with patient-specific information. The following example illustrates recommendations and their interactions. Example 2.1. The two recommendations R1 and R2 as in Figure 1 can be considered in (contradiction) interaction, because they recommend opposite actions.1 So let R = fR1; R2g and assume I = f(R1; R2; )g. Intuitively, for a generic patient, NSAID—e.g. Aspirin—should be administered. If, however, the patient exhibits Gastro. Bleeding, then R1 and R2 are in conflict and there are arguments for both administering and not administering Aspirin.
To resolve the conflict in this case, one could administer a different NSAID, such as Ibuprofen. However, in more complicated situations such alternatives may not be readily available, whence certain actions should not be taken (i.e. certain recommendations cannot be followed). 2.2
An implementation of TMR (see for instance guidelines2.eculture.labs.vu.nl/swish/p/ datasetMaintenance.swinb) allows for the computational representation of clinical guidelines using standards such as the Resource Description Framework. We are thus able to represent guidelines in a manner that makes them amenable to the automatic instantiation of ABA+ frameworks for reasoning with guideline recommendations.
Similarly, the EHR data required to reason with guidelines in light of patient-specific information can be extracted automatically via pieces of middleware running within GPs’ practices. These pieces of middleware are designed to communicate with the Application Programming Interface of a locally installed EHR system, and communicate patient record information, at the discretion of the practitioner, to us for use. Patient information can then be modelled as part of a given TMR implementation, such as in the form of a set of additional external rules, prior to being used in the reasoning process, or delivered to the reasoning engine separately.
This flow of data creates a decision support pipeline, in which potentially conflicting guideline data, along with EHR data, is passed to a reasoning engine that returns nonconflicting recommendations for use by the system. 2.3
Argumentation is a branch of the field of Artificial
Intelligence concerned with reasoning with partial and conflicting
information. For example, medical information is often
partial, because it may be infeasible or simply unreasonable to
record all the possibly relevant patient information; medical
1Note well that a hierarchy of actions is assumed
An important feature of many argumentation formalisms is that they are inherently interpretable and afford explainable reasoning. What this amounts to is the construction of arguments and counterarguments for explicit claims, based on explicit assumptions, using rules expressing application specific reasoning patterns. In addition to providing inspectable arguments and counterarguments for or against claims that may encode beliefs, decisions etc., argumentation allows for questioning the assumptions underlying the arguments and for a continuous addition of new assumptions (and thus arguments). With this, one can explain why e.g. a particular decision was taken, i.e. what were the arguments for and against it, and how can one further question and/or support that decision.
In this work we use a well-established and
broadlystudied argumentation formalism, called ABA
An ABA+ framework is a tuple (L; R; A;¯¯¯; 6), where: (L; R) is a deductive system with L a language and R a set of rules of the form j0 j1; : : : ; jm with m > 1, or of the form j0 >, where ji 2 L for i 2 f0; : : : ; mg and > 62 L; j0 is the head and j1; : : : ; jm the body of the rule; j0 > is said to have an empty body and called a fact; A L is a non-empty set of assumptions; ¯¯¯ : A ! L is a total map: for a 2 A, a is referred to as the contrary of a ; 6 is a preorder (i.e. reflexive and transitive order) on A, called a preference relation.
As usual, the strict (asymmetric) counterpart < of 6 is given by a < b iff a 6 b and b a , for any a and b . (We assume this for all preorders in this paper.) For assumptions a ; b 2 A, a 6 b means that b is at least as preferred as a , and a < b means that a is strictly less preferred than b .
Throughout the paper, we assume as given a fixed but
otherwise arbitrary ABA+ framework F = (L; R; A;¯¯¯; 6),
unless specified otherwise. If the preference relation 6 in
F = (L; R; A;¯¯¯; 6) is empty or unspecified, i.e. there are no
preferences, then we may refer to F as an ABA framework
Assumptions in ABA+ represent arguable information. For instance, assumptions can represent the applicability of, or an agent’s willingness to follow, a recommendation. In such a case, preferences in ABA+ can represent the relative degrees obligatoriness, or willingness to follow, the recommendations. We will exemplify various ABA+ components in Section 3. We next give notions of arguments (as deduction trees) and attacks in ABA+.
An argument for j 2 L supported by A A and R R, denoted A `R j , is a finite tree with: the root labelled by j ; leaves labelled by > or assumptions, with A being the set of all such assumptions; the children of non-leaves y labelled by the elements of the body of some y-headed rule in R, with R being the set of all such rules. A ` j is a shorthand for an argument A `R j with some R R.
For A; B A, A <-attacks B, denoted A < B, iff: a) either there is an argument A0 ` b , for some b 2 B, supported by A0 A, and @a0 2 A0 with a0 < b ; b) or there is an argument B0 ` a, for some a 2 A, supported by B0 B, and 9b 0 2 B0 with b 0 < a.
The intuition here is that A <-attacks B if a) either A argues contra something in B by means of no inferior elements (normal attack), b) or B argues contra something in A but with at least one inferior element (reverse attack).
If A does not <-attack B, we may write A 6 < B. For ABA frameworks (L; R; A;¯¯¯) we often drop the subscript/prefix < and say e.g. attacks, written . Note that without preferences, an attack from one set of assumptions to another boils down to the former set deducing the contrary of some assumption in the latter set.
In the setting of guideline recommendations, sets of assumptions will represent sets of recommendations, and they will induce arguments for or against following recommendations. The attacks among sets of assumptions (recommendations) will arise due to existence of interactions. The preferences may come from e.g. the patient or the clinician.
The reasoning in ABA+ is realised through the semantics. Intuitively, a semantics gives conditions that a set of assumptions needs to satisfy in order to be ‘acceptable’, or ‘good’. The conclusions derived from acceptable assumptions represent a coherent set of beliefs, decisions to make, actions to take, etc., depending on the problem formulation, and are thus deemed as the reasoning outcomes. We next give notions used to define ABA+ semantics. Let A A.
The conclusions of A is the set Cn(A) = fj 2 L : 9A0 ` j; A0 Ag of sentences concluded by (arguments supported by subsets of) A.
We next give three basic requirements for sets of assumptions to be ‘good’, or collectively acceptable. The first one says such a set should include all assumptions it makes. 1. We say A is closed if A = Cn(A) \ A, i.e. A contains all assumptions it concludes.
We say F is flat if every A A is closed. We assume ABA+ frameworks to be flat, unless specified otherwise.
The second one expresses that to be acceptable, a set should not be conflicting, i.e. not to <-attack itself. 2. A is <-conflict-free if A 6 < A.
The third says that a ‘good’ set should defend against counterarguments; we first define the notion of defense.
A <-defends A0 A if for all B A with B < A0 it holds that A < B.
So finally, 3. A is <-admissible if it is <-conflict-free and <-defends itself.
These are arguably three ‘minimal’ requirements for accepting a given set of assumptions (as well as arguments based on them). Note that they are quite weak, because, for instance, the empty set of assumptions is always <admissible. However, not much can in general be concluded from 0/. Thus, ABA+ semantics impose additional requirements for acceptance of assumptions and the associated conclusions. In this paper we use one particular such semantics which says that a ‘good’ set of assumptions should be as large as possible, as follows.
A set E A of assumptions is a <-preferred extension of F = (L; R; A;¯¯¯; 6) if E is -maximally <-admissible. In other words, with <-preferred extensions we are aiming to conclude as much as we can without contradicting ourselves, whilst being able to defend ourselves.
For ABA frameworks we often drop the prefix < for the notions above.
3
Mapping TMR and EHR to ABA+ In this section we discuss a mapping from TMR to ABA+, augmenting the guideline recommendations and their interactions with patient specific information based on EHR.
For the purpose of mapping TMR instances to ABA+, we assume a simplified TMR whose instances are recommendations given as tuples (R; A; d (R); P; E; V; C) with (i) name R, (ii) action A, (iii) deontic strength d (R), (iv) properties P = hP1; : : : ; Pni, for n > 1, (v) effects E = hE1; : : : ; Eni, (vi) initial values V = hv1; : : : ; vni of effects on properties, (vii) contribution values C = hc1; : : : ; cni.
We identify any such recommendation with its name R.
We next describe a mapping from TMR to ABA+. We omit the cumbersome formal details in the interest of space. We will exemplify the mapping in Section 4.
Given a recommendation (R; A; d (R); P; E; V; C), we construct the following: a) an assumption R 2 A representing the possible applicability of the recommendation; b) a rule A R 2 R representing that action A is recommended by R; c) for each property Pi and its corresponding effect Ei, a i i about effect EAi t2o pRropreeprtryesPen.ting that action A brings rule E P i
We use the additional components of recommendations to model interactions. Specifically, suppose recommendations (R1; A1; d (R1); P1; E1; V1; C1) and (R2; A2; d (R2); P2; E2; V2; C2) are in contradiction, with actions A1 and A2 recommended positively (d (R1) > 0) and negatively (d (R2) < 0), respectively. That means R2 can be argued against on the basis of R1 and the presence of the interaction. On the other hand, R1 can be similarly argued against on the basis of R2 and the presence of the interaction, but only if a given patient presents some condition affected by A2 that contributes negatively to the patient’s well-being.
Thus, given (R1; R2; m) 2 I, we construct the following: d) R2 R1; int1;2; e) R1 R2; int1;2; vP, where P 2 P2 is a property with initial value v 2 V2 and contribution = c 2 C2. (When the initial value v of P is indeterminate ?, we use only P in the body of the rule.) Here, int1;2 2 L represents (R1; R2; m) 2 I. The rule in d) says R2 should not be followed if (i) R1 is followed, and (ii) R1 and R2 are in contradiction. The rule in e) says R1 should not be followed if (i) R2 is followed, (ii) R1 and R2 are in contradiction, and also (iii) the condition vP is present.
The interaction’s modal strength determines whether the interaction can be argued about or not: f) given m, 1. if m = , let int > 2 R; 2. if m = , let int 2 A.
The rule int > 2 R represents that the interaction is sure to happen, i.e. it is a fact, and so there is no way to disagree with it. However, as an assumption, int 2 A represents that the interaction is not certain to happen and so can be argued against by putting forward arguments for the contrary int.
Now, the patient specific conditions can be similarly represented as either facts or assumptions: g) given a patient condition cond, 1. either let cond > 2 R; 2. or let cond 2 A.
Whether the conditions can be argued about or not depends on the context. For instance, it may be debated whether a patient is taking certain medications (confirmation of which is part of standard hospital procedures), but it may be certain that a patient has mild Angina.
Of particular interest are those conditions that appear within recommendations as properties affected by actions. Specifically, if some condition as property P (and possibly value v) matches that in a recommendation, then the addition of P (or vP) as either a fact or an assumption may trigger a rule concerning interactions of recommendations, such as e) above. In this way a patient’s EHR can meaningfully augment the TMR model when represented in ABA+.
Given the assumptions and rules constructed from recommendations in R and interactions in I as per points a)–g) above, we can define an ABA framework (L; R; A;¯¯¯) with contraries on assumptions a 2 A being new symbols a and the language L given given by the symbols appearing in A, R and fa : a 2 Ag. In (L; R; A;¯¯¯) we can construct arguments and counterarguments for actions based on (the possibility of following) recommendations and patient specific conditions. The semantics (of e.g. preferred extensions, see Section 2.3) then allow to determine sets (i.e. extensions) of collectively non-conflicting recommendations for a given patient. The conclusions of such extensions then yield, in addition to the recommendations to be followed, the actions to be taken as well as their consequences in terms of effects on the patient’s conditions.
In addition to recommendations and patient EHR information, we may also have preferences over e.g. courses of action, of one or the other party involved. For instance: the patient may prefer one medicine over another, according to what they are used to; or the clinician may prioritise one course of action over another, based on their professional experience; or else, the hospital may have preferences over treatment methods, judging by the information on their success in the local geographical region.
Preferences can be naturally incorporated in ABA+ by extending the ABA framework (L; R; A;¯¯¯) with a preference relation 6 to obtain an ABA+ framework (L; R; A;¯¯¯; 6). For example, if action A1 suggested by recommendation R1 is preferred over action A2 suggested by recommendation R2, then the preference R2 < R1 can be added. Such preferences then possibly affect the reasoning outcomes in that the extensions (and the associated conclusions) obtained respect the preferences specified.
Last but not least, the reasoning process in ABA+ instantiated with TMR, EHR and preferences is fully transparent and explainable. Indeed, the assumptions and rules on which the arguments are based are clearly stated, the attack relationship among arguments is constructively defined based on the explicitly given assumptions and preferences, and the semantics comprehensively express reasonable requirement for argument/assumption acceptance.
We illustrate the mapping to and reasoning in ABA+ with a use case in the next section.
4
The COPD use case developed sets up the boundaries and scope of the problem that is mapped and resolved throughout the rest of the model. The use case is established as existing within the context of a secondary health-care system and creates an artificial scenario of a patient that would present themselves within the health-care system with symptoms typical to COPD, and illustrate how they would be managed within the health-care system with regards to following official guideline recommendations. 4.1
The patient presents to a primary health-care setting complaining of breathing difficulties and increased fatigue during exercise, and following standard diagnostic procedures not covered by the model, is diagnosed with mild stable COPD. As for the treatment choice, a decision for medication is made based on the patients vitals as some of the main deciding factors in the form of: (i) Blood gas levels; (ii) Spirometry results; (iii) Age; (iv) Current lifestyle habits; (v) Existing comorbidities. For the purpose of illustrating the argumentation component of the model, the patient is assumed to have a pre-existing condition in the form of mild Angina, which was diagnosed at an earlier point in time.
Following the NICE COPD management guidelines
Similarly, for patients who present with a mild form of COPD, the NICE guideline recommends that the patient undertake regular exercise to boost the functioning of their cardiovascular system. It is easy to imagine a situation where this would not be applicable, for example if the patient is suffering from joint pain, or peripheral artery disease. In such a case, the expected prescription would not only be unhelpful, it would in fact be damaging to the health of the patient. A contraindication to the aforementioned exercise can be found within the clinical guidelines for the specific comorbidities, highlighting the near unlimited potential complexity of a clinical course.
As such, the stable COPD with mild angina use case serves as a simple illustration of the concept that can thereupon be further expanded to encompass multimorbidities and conflicts in medication, and outpatient management. 4.2
For illustrating how ABA+ deals with interacting guideline recommendations, we take two recommendations from the COPD use case, namely administering SABA and not administering standard SABA. The two recommendations are in contradiction, because standard SABA is subsumed by SABA. Thus, R consists of the following recommendations. 1. (R1; A1; d (R1); P1; E1; V1; C1) with: (i) name R1; (ii) A1 = SABA; (iii) d (R1) = must; (iv) P1 = hLung muscles; Airwaysi; (v) E1 = hrelaxes; dilatesi; (vi) V1 = h?; ?i; (vii) C1 = h+; +i; 2. (R2; A2; d (R2); P2; E2; V2; C2) with: (i) name R2; (ii) standard SABA; (iii) d (R2) = must not; (iv) P2 = hAnginai; (v) E2 = hincreasei; (vi) V2 = hmildi; (vii) C2 = h i.
We assume that the interaction between R1 and R2 is certain, so that I = f(R1; R2; )g. Importantly, R and I yield the assumptions R1; R2 2 A and the following rules in R: R2 R1; int1;2; R1 R2; int1;2; mild Angina; int1;2 >. (For simplicity, we omit to specify the rules regarding the actions as well as their effects on properties.)
Given that the patient has a mild Angina, we have mild Angina > in R, representing the patient specific condition.
In the resulting ABA framework (L; R; A;¯¯¯) we find arguments fR1g ` R2 and fR2g ` R1, so that fR1g and fR2g attack each other. The two sets are thus preferred extensions of (L; R; A;¯¯¯), concluding respectively administering SABA and not administering standard SABA. As one of the conclusions is not to take any action, one can either employ preferences, or pass the information back to the TMR implementation to refine recommendations, if possible.
Regarding preferences, the clinician could insist that not worsening Angina takes priority over addressing COPD by way of administering standard SABA. Thus, the preference R1 < R2 could be added to obtain the ABA+ framework (L; R; A;¯¯¯; 6). There, fR2g < fR1g, but fR1g 6 < fR2g, so that R2 forms a unique <-preferred extension and no action is recommended.
Following this, or otherwise prior to employing preferences, one can look for a refinement of the generic recommendation R1. And indeed, recommendation R3 can be found that is like R1, but suggests administering nebulised SABA instead. Adding R3 to the existing ABA/ABA+ framework, or otherwise constructing a new one with R3 replacing R1, leads to obtaining <-preferred extensions which conclude administering nebulised SABA. This is in agreement with what should actually be done.
Note well that reasoning with conflicting information (as well as preferences) and yielding non-conflicting conclusions is not the only thing allowed by argumentation. In addition, argumentation affords means to inspect and explain the reasoning. In particular, the extensions obtained, as well as arguments for specific claims and/or based on specific assumptions, can be presented to the clinician or more generally a user of the LHS. This way the user can interact and provide feedback to the system so that it evolves and yields better reasoning outcomes in the future. We leave the description and implementation of feedback integration within the system for future work.
Argumentation has already been successfully applied in
health-care, see e.g.
There are several works that use both argument construction and argumentation semantics for reasoning with medical knowledge, as we do in this paper.
For instance,
The recent CONSULT project
Other works incorporating argumentation and preferences focus on helping clinicians to construct and evaluate arguments for and against decisions. As such, they do not automatically populate their argumentation frameworks with guideline knowledge or EHR data, and do concern reasoning with clinical guideline recommendations, but are nevertheless related to our work due to the use of argumentation semantics for reasoning.
For instance,
In some works that use argumentation components to
model information, argumentation semantics are not used
to execute the reasoning itself. For instance, in one of the
earliest related works,
An argument aggregation mechanism for reasoning with
guidelines is used in
As for non-argumentative approaches to reasoning with
interacting guidelines,
Our work is different in terms of both reasoning and
representation. Regarding representation, as indicated by
Other approaches to reasoning with guidelines and
temporal as well as clinical constraints exist
We described work in progress towards a Decision Support System that will use Transition-based Medical Recommendation model (TMR) and its integration with electronic health record (EHR) data to facilitate automated execution of interacting clinical guidelines by taking into account patient’s individual medical history and preferences of various parties involved. In particular, we proposed the structured argumentation formalism ABA+ for automated reasoning with conflicting clinical guideline recommendations as well as patient information and preferences. We also discussed how ABA+ yields interpretable and explainable medical decisions for execution of guideline recommendations.
Future work on implementations of TMR involves
constructing standard interfaces that can be queried ad-hoc by
other systems such as argumentation frameworks. Similar
efforts to increase the interoperability of EHR data include
the examination of techniques to standardise independent
vendor formats to a single target format such as HL7’s FHIR
In terms of argumentation, there are several directions for future work. Firstly, we will aim to account for various types of interactions that accompany the TMR model, including those concerning conflicts such as side-effects, but also other interactions such as safety. We will also study the integration of preferences from various sources, and possible interactions of those preferences. In addition, we will explore various ways of extracting explanations from the argumentative reasoning process, such as visualising arguments and their relationships, as well as using natural language generation to yield textual explanations of the reasoning outcomes. Finally, we will make use of the well-established theoretical properties of, particularly, ABA+, regarding reasoning and preferences, and establish what they mean in the context of medical decision making.
Acknowledgements The authors were funded by the EPSRC project EP/P029558/1 ROAD2H: Resource Optimisation, Argumentation, Decision Support and Knowledge Transfer to Create Value via Learning Health Systems, except for Martin Chapman who was funded by the EPSRC project EP/P010105/1 CONSULT: Collaborative Mobile Decision Support for Managing Multiple Morbidities.