Automated conflict resolution between multiple clinical pathways: a technology report

INTRODUCTION

By 2018, it is estimated that the number of people in the UK with three or more long-term conditions will have grown from 1.9 to 2.9 million.1 The management of patients with co-morbidities is complex, relying on a range of interacting social agents including physicians, administrators and the drive for patient-centred care. Yet support for clinicians intended to improve the quality of healthcare is based on some 250 clinical guidelines that almost exclusively focus on single conditions.2 The result is that applying multiple guidelines to a patient can result in conflicting recommendations for care leading to calls for an improved integration of existing guidelines to better support patients with multimorbidities.3

These guidelines frequently use graphical descriptions of evidence and are often represented in a single or series of flowcharts.4^,5 As such they share with software system specifications, the central tenets of a series of executions of ordered sequences of activities or tasks. The interactions these sequences describe can be modelled using a number of approaches such as sequence or activity diagrams,6 workflow languages such as business process model and notation (BPMN),7 or variants of Petri nets.8 Previous studies has explored the creation of algorithms for merging or ‘composing’ models in these languages9^–13 in order to create a unified model from smaller constituent models, or views. However, in healthcare as in software engineering, a conflict may arise when models are merged but individual executions or actions are incompatible with others.

In this study, we are investigating the use of automated methods of detecting conflicts between multiple clinical pathways and proposing solutions that resolve the conflict. We will consider the specific nature and parameters of each guideline, specific conditions of individual patients, cross-referencing pathways to determine which aspects of the relevant pathway are followed and when. These methods will be developed into a prototype software tool presenting an automated method for navigating multiple clinical pathways for patients with multimorbidity that detects any conflict between pathways and makes suggestions as to how these conflicts might be resolved, sympathetic to the priorities of the care provider and patient. Ultimately, our tool will lead to improved patient outcomes and increase the cost-effectiveness of treating patients with multimorbidity.

DEVELOPMENT

To identify possible conflicts, we are transforming models into logical statements and using them to detect conflicts between various steps on each ‘pathway’ using constraint solvers.14^–17 These have been used successfully to detect conflict in the composition of static models of processes.18^–20 More recently, the use of constraint solvers has been explored for dynamic models similar to those presented in healthcare.19^,21 In this instance, the solvers recognise that the resolution of a conflict can entail different compromises and affect various measures such as time, resource and cost.

Our work consists of three phases.

Phase 1: modelling clinical pathways

The first phase builds on the graphical process modelling language BPMN7 to accurately model clinical pathways and applies it to six pathways representing some of the most common chronic diseases: hypertension, ischaemic heart disease; chronic obstructive pulmonary disease (COPD); Type 2 diabetes mellitus; depression and osteoarthritis (OA). Describing this range of pathways in BPMN allows us to clarify any issues related to the expressiveness of the language or any ambiguities that might exist when attempting to capture clinical pathways.

Having developed the language and mapped the specified pathways, we can produce a formal model that captures care pathways unambiguously. This model will capture pathway characteristics including the periodic nature of appointments and the temporal validity of certain parameters,22^,23 for example, the value of blood test results at a specific point in time, drug interactions or intolerance and so on. It will be capable of specifying constraints over the compatibility of treatment within three domains: the scheduling of appointments, medication and behavioural or lifestyle advice. This formal representation will be based on a restriction of the BPMN notation endowed with semantic concepts inspired by coloured petri nets (CPN)24 to express the dynamic behaviour of the models. CPN and equivalent models have previously successfully been used to model and reason about distributed systems for the dynamic interpretation of behavioural composition mechanisms.13^,19^,21^,25 Elsewhere, BPMN has been successfully used to model clinical workflows in a static manner.26^,27 We will confirm the most suitable way to define additional relations and functions over events to encode the necessary dynamic information relating to patients’ interaction with their care providers and subsequent actions. An example of one of our modelled pathways is shown in Figure 1.

Request permission

Figure 1

Phase 2: recognition and resolution of conflict

Pathway composition and care conflicts

Each care pathway represents sequences of medical procedures (events) that may be applied to a patient, together with decision criteria guiding which sequence of events will apply in a particular case, including interactions between the patient and provider. These care pathways are similar to workflow models,28^,29 which represent the partially ordered occurrence of events and interactions between components in a software system. As a result, automated constraint solvers such as Z3,17^,30 can be used to automatically detect whether the ordering of events specified in one model is in conflict with the ordering of events in others.13^,31 In the context of healthcare, one example is when two pathways prescribe drugs which should not be used at the same time. Technically, this can be defined as a constraint, that is, the occurrence of one event disallows the occurrence of another.

We give a limited example in Figure 2. Here, we show a fragment of a pathway model for treating osteoporosis (OA, left) and COPD (right). The majority of the models have been omitted for clarity. The OA model specifies for a number of activities to be carried out in parallel, including the prescription of non-steroidal anti-inflammatory drugs (NSAIDs) to the patient, but only if neither NSAIDs nor corticosteroids are already prescribed. The medications prescribed to a patient are described by the values of data variables in the model. (Here, we use integers, to allow for future dependency on how much medication is being taken.) The ‘guard’ annotations indicate the restriction on prescribing NSAIDs, while the ‘data’ annotations indicate the need to record that the patient is now taking NSAIDs, once a prescription has taken place. The COPD fragment similarly depends on, and modifies the status of, corticosteroids. If a patient is following both the pathways, then there is potential for a conflict between these activities: if NSAIDs is prescribed by the OA pathway, then corticosteroids must not be prescribed by the COPD pathway, and vice versa. Depending on the stage at which the patient is on either pathway, these activities may occur at different times, the set of drugs prescribed to the patient may be different, and so on. Capturing pathways based on BPMN and specifying their composition and constraints based on data values will allow constraint solvers to solve the composed model for the sequences of activities which are valid for a particular patient and situation, and which must be avoided (and why). This is a very simple illustration of a conflict between models and our continuing work will extend this principle to account for other types of conflict. Principally, those that can occur between lifestyle recommendations such as a particular diet or exercise regime though we expect that further sources of conflict will be considered relating to the preferences and priorities of clinicians and patients and the scheduling of appointments or procedures, during subsequent stages of our work.

Request permission

Figure 2

For each of the care pathways, we are using the Z3 solver to search for a solution that satisfies all constraints. If the care pathways have no conflicts between them, we obtain a new model of the integrated pathways. Otherwise, the analysis identifies the conflicting logical constraints, which allows us to identify which parts of the pathway models are in conflict. This underpins the creation of algorithms to map the solution (or conflicts) back onto the original pathway models for interpretation by clinicians and provides a basis for automated resolutions to be recommended.

Since our models of pathways are always finite, a conflict exists only if the solver can detect it.21 Where there is a loop – a common trait within clinical guidance, for example, testing for HbA1 in diabetics – we will generate a finite number of iterations of the loop over which to evaluate the model. The use of automated solvers in detecting these conflicts means that we can seek conflicts at scale and in a timely fashion.

Automated conflict resolution

As the number of pathways increases, it is critical to adopt the most suitable method of conflict detection and resolution. We will investigate automated methods for changing those parts of pathway models which are causing conflict. To enable this, we are developing a method of identifying the solutions that require the least changes to the models. To do so, we will incorporate a concept of distance metrics into our constraint solving practices. Since sequences of tasks representing a pathway can been seen as graphs, graph edit distances, which measure the number of changes between two graphs required to make them equal, are a suitable basis for such a metric.32 This will allow us to present the clinician with a series of choices ranked in a meaningful manner, as the tool will propose all possible solutions referencing the number of changes to the various pathways needed to accommodate the solution, and so allow a better-informed decision to be made.

APPLICATION

As described, the increasing number of patients with multiple and frequently long-term conditions presents a challenge to the existing models of care. Though generic guidance for multimorbidity has been produced recently,34 much of the evidence-based guidance is still focused on the treatment of single conditions. This means clinicians are making decisions for one morbidity without having the tools to identify, illustrate, or understand the clinical consequences on another pre-existing condition. We will initiate a software library for pathway models consisting in the first instance of the modelled pathways constructed as part of this project. These will be freely available as a ‘plug-in’ meaning they can be used with existing software systems.

The methods and tools we are developing have the potential to maximise the well-being and quality of life of patients with chronic disease, and benefit their families and carers. By optimising the patient management, our proposed techniques can help reduce polypharmacy, avoidable hospital admissions and procedures, and allow us to implement and audit the best practice. We will also explore the theoretical and practical considerations of the applicability of constraint solvers to other sources of healthcare information technology systems. The application of such techniques has the potential to create tools and technologies to address the national and global health challenges.

DISCUSSION

Medical decision-making is a complex and evolving process particularly in the increasingly busy primary care environment where continuity of care is decreasing,34 and clinicians are reliant on generic guidance that in such busy settings can often be ignored.35 The graphical language we are developing can not only be used to model centrally disseminated guidance but also used to create bespoke care pathways reflecting the local needs of local patients, organisations and commissioners presented in a readily interpretable display.

BPMN has become the de facto and ISO36 standard for process modelling. Its intuitive graphical model37 has been found suitable for the capturing of processes by domain experts without specialist modelling skills, and facilitating communication between non-specialists.26^,27^,38 BPMN has been studied in healthcare and assessed as suitable for modelling and visualising clinical pathways39^,40 and is being chosen as the modelling notation an increasing number of studies.26^,27^,38^–40 Critically, for our purpose to specify conflicts arising from interaction with data, it is designed for extension,39^,41 and for formal analysis of modelled pathways, semantics can be properly specified for subsets of BPMN.42^,43

Other graphical notations have been proposed for modelling processes. Some, such as Petri nets44 and YAWL,45 do have a rigorous semantics, but either do not account for data (Petri nets), or are over-complex for our purposes (YAWL), or are more suitable for expert modellers (both). In the healthcare domain, a number of Computer Interpretable Guidelines (CIGs) have been proposed. However, none of these have yet become standard, and their bespoke process notations and interaction with data are tightly integrated with their broader facilities for decision support, knowledge management and process automation. We therefore base our notation on BPMN for the benefits of widespread acceptance, ease of interpretation and extension, to allow ease of use by non-specialists while being able to formally specify clinical guidelines.

The acknowledged pressure on clinicians analysing large quantities of data to manage increasingly complex care regimes has led to the development of clinical support systems that can provide readily interpretable medical information. Our approach to manage complex patients is based on producing a series of interactive pathways where any combination can be selected, the conflict between them automatically identified, and suggestions for resolution generated to inform the subsequent decisions. There are, however, other approaches and recently the use of fuzzy logic has gained in popularity.46 This also offers the opportunity to integrate complex human knowledge with computer-aided techniques through tools such as CCTool.47 Many of these rely on the Theory of Change methodologies that combine perspectives of a range of stakeholders to meet a pre-specified goal.48 The resultant maps share much in common with the care pathways that we are creating based on NICE guidance.2 However, the benefit of our approach is that the potentially inhibiting complexity of taking a whole systems view is avoided by building a system one pathway at a time. That these pathways can be used to create unambiguous logical models interpretable by constraint solvers means we can identify potential conflicts between pathways and provide targeted support for clinicians managing multimorbid patients. Such tailored support is missing from the clinical support systems currently in use.

None.

I declare on behalf of all authors that we have no significant competing financial, professional or personal interests that might have influenced the content or the work described in this manuscript.

As lead author, I can confirm that this is a technical report and as such only preliminary data are available.

The main funding for this project was provided by Engineering and Physical Sciences Research Council EP/M014401/1

Litchfield and Turner were responsible for the conception of the work and the design of the study. Litchfield led the drafting of the article with input from Weber, Backman. Lee, Turner and Ferreira Filho all provided critical revisions. The final version was drafted by Litchfield and approved by Turner, Backman, Ferreira Filho, Weber and Lee.