- Email: [email protected]
A principled approach to the design of healthcare systems: Autonomy vs. governance
ARTICLE IN PRESS
Reliability Engineering and System Safety 91 (2006) 1576–1585 www.elsevier.com/locate/ress
A principled approach to the design of healthcare systems: Autonomy vs. governance A. Taleb-Bendiab, David England, Martin Randles, Philip Miseldine, Karen Murphy School of Computing and Mathematical Sciences, Liverpool John Moores University, Byrom St, Liverpool L3 3AF, UK Available online 19 April 2006
Abstract In this paper, we look at decision support for post-operative breast cancer care. Our main concerns are to support autonomy of decision making whilst maintaining the governance and reliability of the decision-making process. We describe the context of our work in the wider medical setting. We then present a set of decision support tools based on the situation calculus as a means of maintaining the integrity of rule bases underlying the decision-making system. The decision support system, Neptune, allows for the authoring, maintenance and delivery of decisions in a self-governing framework. Finally we discuss the implications of our work. r 2006 Elsevier Ltd. All rights reserved. Keywords: Decision support; Breast cancer care; Autonomy; Self-governing systems
1. Introduction 1.1. Evidence-based era This project on decision support for post-operative breast cancer care [1] raises a number of interdisciplinary questions in a complex and emotive area. The project is collaboration between computer scientists, statisticians and clinicians, a complex arrangement in itself. The nature of the subject involves the making of difficult decisions as clinicians and patients are faced with life and death choices. The decision support processes must therefore follow methods that promote the safety and reliability of the outputted decision whilst also maintaining system robustness and fault tolerance. Additionally from an HCI viewpoint we are also faced with supporting and not supplanting clinician’s judgments. There are also wider issues arising from the implications of our studies regarding the historical clinical data and what that might mean for future approaches to prognosis. In an earlier paper [2], an approach to process understanding, in breast cancer care, was discussed. It described how decisions on post-operative breast cancer treatment Corresponding author. Tel.: +44 151 231 2271; fax: +44 151 207 4594.
E-mail address: [email protected] (D. England). 0951-8320/$ - see front matter r 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.ress.2006.01.011
are currently governed by a set of medical guidelines including the National Institute for Clinical Evidence (NICE) guidelines [3] in which the decision process is as follows (Fig. 1): The clinician uses available data with a staging method to define the patient risk category. The risk category is then used to determine the type of treatment (T1yT6) that the patient could be offered. Medical experts are expected to make the best available decision in the circumstances. However, this becomes increasingly difficult as available medical knowledge expands. Computers and decision support system software have the capacity to handle and deal with all this information. In general computers are better than humans at managing large amounts of information and the resulting complexity. Thus, the guidelines approach has the potential to make medical practice more consistent, efficacious, safer and cost effective [4]. However, guidelines can cause benefit or harm and need to be ‘‘yrigorously developed, evidence based guidelines [to] minimise the potential harms’’. Additionally the uptake by the clinicians needs to be addressed as, in practice; guidelines are often not used [5]. The evidence-based approach to the delivery of medical care has gained wide recognition within the healthcare community, advocating that decision making should use current knowledge and clinical evidence from systematic research [6]. In breast cancer care, in particular, there are
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
T1 Input Patient Data
T2 T3
Staging Method for Risk Assessment T6
T4 T5
Fig. 1. Guideline process.
currently a number of staging methods widely used by clinicians, in particular the Nottingham and Manchester staging systems. However, there is no standard method to support clinicians’ decision-making processes as to how and when to include new evidence, and how to validate emerging local patient data patterns or other models and practices from elsewhere. This means that there is no standard way to ensure that clinicians are following accepted guidelines or deviating from them. There may be valid clinical reasons why a standard decision path is not chosen (e.g. the age or infirmity of the patient) but these decisions are not currently recorded in a standard way. In comparison computer implemented guidelines have the potential to be better used at a local level by:
improving accessibility by the clinical team, performing additional tasks such as prescription writing, warning of potential hazards, and providing alternative views of the information.
On a larger scale; systems can take on functions such as: recommendation, presentation, documentation, registration, communication, explanation, calculation and aggregation. There are many contributory factors to the complexity of designing these systems, some of which are described below:
Environment and context—The aims of national initiatives such as NPFit/PACIT [7,8] in driving down costs and errors, etc. The complexity of the context depends on the observer. So the views of the various reforming agencies almost certainly differ from those of the practitioners. The autonomy of clinicians versus the governance requirements of clinical audit and traceability to support for instance clinical governance. In any case the autonomy of action is bounded within set limits. This is a complex relationship that must be represented in any up to date implemented system. Resource limitations—staffing, drugs, radiology, etc. Again resources are bounded. The limitations of medical knowledge and how that knowledge evolves. So it must be a priority to ensure that new knowledge can quickly and easily be assimilated into the system without stopping and restarting.
1577
The co-evolution of knowledge and the needs for system validation and safety. So the system needs to evolve in a safe, reliable and predictable manner as prescribed by the governance strictures. The requirements for safe solutions and effective treatment, as part of the overall goal of engineering a reliable safety critical system. The (moving) requirements for knowledge elicitation to be used to update the decision processes. The ability of computer scientists to encode medical knowledge is limited to expert advice gained from clinicians. The limitations of data mining approaches as a means to supporting evidence-based, decision making.
Finally, there is the concern over the impact of the introduction of computer support in the decision process and the effect this may have on clinical practice. 1.2. National programmes In both the UK and US there are national initiatives to introduce greater use of IT in clinical settings. The broad aims of the NPFit and PACIT programmes are similar. They aim to streamline data processing to cut costs and reduce clinical errors. For example, it is proposed that electronic prescribing of medicines will cut costs in paperwork and reduce prescribing errors which account for a large number of patient deaths (44,000–98,000 deaths caused by all types of medical errors in the USA). Both schemes aim to introduce electronic patient records, again to cut costs of paper records and reduce errors from paperbased systems. Both systems also look to more clinical governance and audit of medical processes so that medical staff are more accountable for their actions. The UK initiative is already displaying the signs of a large project out of control with the projected costs of £6Bn rising to between £18Bn and £31Bn. The lack of user centred design is evident by a recent [9] poll showing 75% of family doctors are not certain that NPFit will ever meets its goals. The first stage of the electronic appointment systems has largely failed to meets its use targets. However, a smaller scale introduction of region-wide IT in the Wirral was more widely accepted with 90% of family surgeries and the vast number of patients accepting the system. Thus IT systems can succeed. This is important for our work, for in order to succeed, it requires a working IT health infrastructure. Furthermore the twin goals of cost and error reduction may be mutually incompatible. As Reason points out [10] organisations have processes for productivity and safety but circumstances will arise, either through unsafe acts or latent system weaknesses, which lead to organisational failure. Safety protocols may be violated in the name of efficiency or sets of latent weaknesses will line up to cause an accident. Many individual errors are the result of cognitive under-specification [11] of the user’s tasks. In this project we aim to over-specify and support
ARTICLE IN PRESS 1578
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
clinical tasks by first describing both the decision and system control processes and representing them as agentbased deliberative architectures in the situation calculus. This leads to a natural implementation in a custom designed language, Neptune that implements the situation calculus expressions within a grid based architecture called clouds. This will provide a robust means of supporting decision making and ensuring that chances to decisions protocols remain valid. Some of the sources of complexity in the design of healthcare systems are addressed. More specifically, we are interested in safe and reliable decision support for post-operative breast cancer care and the wider lessons we can learn from our experiences. Accordingly, the next Section 2 provides an overview of related work in the area of support for clinical guidelines. Section 3 then gives an overview of the formal methodology used in our approach. Whilst Section 4 shows the development process from system description to formal model to the actual implementation. This approach is evaluated in Section 5 with conclusions and future work closing the paper in Section 6. 2. Related work Clinicians and co-researchers have developed evidencebased guidelines to improve the quality of patient care, aiming to reduce some of the complexity we outlined above. Software implementations of guidelines are more likely to be used by clinicians if they provide patient specific advice during consultations [12]. The provision of such support relies upon a machine interpretable guideline model. There are a number of general features that such a guideline-based decision support model needs to. These include representation, structure, expressiveness, complexity management, knowledge acquisition and safety/reliability. For example, the Arden Syntax [13], was developed to act as a hospital ‘‘watchdog’’ monitoring clinical data values. It is a text-based programming language for encoding medical logic modules (MLMs). However, it is difficult for non-computer literate medical experts to use. Similarly augmented decision tables (ADTs) [14] have also been used, to extend the rule-based functionality of Arden, by augmenting rules with additional data such as probability and utility. However, neither the Arden Syntax nor ADTs provide support for conceptualising a multi-step guideline that evolves over time and which allows the accrual of evidence. This is why the next generation of guideline models has focussed on object-oriented, taskbased formalisms that unlike simple rule-based systems allow:
Also, they provide methods of handling complexity such as: data abstraction, data hiding and modularity. The hypertext graphic mark-up language (HGML) [15] uses XML to give a descriptive representation. Using XML elements it performs the task of identifying and connecting statements, conditions and recommendations. However, this limits the range of decision making as, for example, there is no way to encode Boolean conjunctions. In contrast the guideline elements mark-up (GEM) [16] is a descriptive XML representation with over a hundred element types making it expressive but also more complicated. There is no link between the clinical knowledge base and the location of the acquired knowledge. The system can therefore contain implied rather explicit decision-making knowledge making the updating of the decision based more complex. What we need is expressiveness of the system representation is without unnecessary complexity. The minimum features we require are: a structure to hold the patient information, the ability to make a decision and to perform actions [17]. Additionally process flow in decision making needs to be controlled by temporal sequencing, looping, multiple entry points or non-deterministic actions. GLIF [18] and Proforma [19] are based on algorithmic designs (Fig. 2) with Proforma having a safety focus based on the red representation language (R2L). Proforma deliberately tries to support expressiveness by a minimal set of modelling constructs. It supports four tasks: actions, compound plans, decisions and enquiries. All tasks inherit attributes describing: goals, control flow, preconditions and post conditions. Safety in computer implemented guideline systems is a critical responsibility. Safety is more likely to be supported in systems where [20]:
there is a recognised software design paradigm being used, knowledge and decision logic are separated, a simple tool kit is used, there is a minimal feature, set expressive enough to encode guidelines in a simple manner, a decision-making process can be followed, and clinician knowledge can be used and the decision overridden.
GLIF stresses the importance of sharing guidelines among different institutions and software systems. Its
COMMIT ALTERNATIVES
the explicit modelling of alternative pathways, flow control, and a visual representation of plans and the organisation of tasks within them.
ACTION
SITUATION
GOALS
ARGUMENTS
DATABASE: REASONING AND BELIEFS Fig. 2. Algorithmic decision process.
PLAN
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
expression language was originally based on the Arden syntax but more recently the object-oriented language GELLO [21] is being used. Both Proforma and GLIF are very expressive and are capable of implementing a broad range of guidelines. This expressiveness, however, means medical experts may not necessarily able to author guidelines without substantial extra training. Also, in a similar way to GEM, there is no way of connecting descriptive text with related implemented guideline content. This makes tracking changes and ramifications very difficult in a guideline database. Finally, the structure of GLIF and Proforma is rigid. The limits the clinicians input it terms of updating guidelines when required and over-riding system decision given particular patient knowledge. This is where the methodology suggested in this paper differs from the standard approaches considered so far. The guideline implementation process is seen as a complete system comprising of both the decision-making process and the self-governance, including clinical governance, of the system itself. We use an agent-based architecture as the basis of: requesting a decision, making a decision, providing the decision, logging the process and providing overall system management. This allows the intrinsic complexity of guideline implementation and management to be modularised. In this way, both quality of service (QoS) and quality of process (QoP) can be assessed within an adaptable, self-contained system. 3. Methodology In our approach, we use the situation calculus [22] for decision knowledge modelling and Neptune system for guideline authoring and decision-making support. This gives us a route from; narrative guidelines derived from our clinical partners, to verifiably correct logical models, and hence on to the enactment of clinical decisions in Neptune. In a multidisciplinary project, this project started by understanding the current decision-making practices as a prelude to systems’ implementations. This will be evaluated using a set of small-scale controlled trials. The proposed method, unlike traditional decision-making techniques, will provide breast cancer clinicians and patients with a more flexible decision-making framework, adaptive to their decision practices. It will also allow for evolution of decision models, decision resources (data) and users concerns. This novel approach will provide important insights into the development of an integrated decision support infrastructure for high assurance decision activities, which will directly contribute to one of the NHS R&D high priority area of ‘‘Medical Devices Directives for cancer patient care’’. 3.1. The process To take a new approach to modelling, validation and enactment of clinical guidelines, our work uses techniques from distributed Artificial Intelligence. In such an ap-
1579
proach, a given treatment recommendation decision tree is conceived of as a human/artificial, multi-agent system. Here, the actions of the agents are governed by a set of system norms, each of which is a set of rules that enable or disable a given desirable or undesirable system behaviour, respectively. Each actor agent, in the system, brings their own epistemic state and behavioural norms to the multiagent environment. So the system norms comprise of, at least, the agents’ shared ontology. Above this the agents retain there own autonomy separate from the shared system’s demands of governance (i.e. maintaining the integrity of the rules). Thus, the agent is autonomous but this is always bounded by the governance strictures enforced on the system via the normative environment. In this way, there is a flux between the self-governance of the system and the bounded autonomy of the local agents. The system norms to facilitate self-governance may relate to the control of the system in maintaining availability, fault tolerance, adaptability, etc. for QoS, or they may be concerned with the output results such as clinical guideline compliance for QoP. In any event the goal is complete system governance within safe limits, encompassing clinical governance. It is a complex process, in itself, to produce safety critical systems. However, the need to permit variability and variety of clinicians’ usage, adds another level of complexity. The autonomy that needs to be retained by the clinician is tempered by the constraints of clinical governance. Thus, if the system is required to take control of management functions the autonomy of the system’s agents is compromised. However, the agents are autonomous, rational and social so computational economy is best served by the agents following the clinical norms. Norms arise from a social situation in that they involve providing rules for a community of more than one individual [23]. The norms can be associated with producing decisions, as a practical application, or with the governance of the system and clinical processes. 3.2. Formal modelling using the situation calculus The following section introduces the Situation Calculus, as a first-order logical method of handling dynamical systems that can then be verifiably implemented in our authoring system, Neptune [24]. The Situation Calculus [25] is especially suited to the analysis of dynamic systems because there is no need for the prior enumeration of the state space so unexpected external events can be accommodated. The frame problem [26] initially limited the applicability of the approach. However, a solution for deterministic actions [22] gave automatic frame axiom representation with effect axioms using the concept of a successor state. This calculus provides an excellent logical implementation framework for autonomous software agents that sense, deliberate and act in unpredictable environments. It takes higher level cognition as a determiner for agent behaviour, modelling agent beliefs and their consequences.
ARTICLE IN PRESS 1580
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
These beliefs include: what is true in the environment, the agents’ knowledge about actions performed by themselves, other agents and the environment, the conditions under which an action can be performed and about the outcomes of its perceptions. These beliefs are modelled in the form of logical sentences conditioning behaviour and how deliberation can lead to action. What-if scenarios can be modelled with branching time-lines and counterfactual reasoning. Thus, a formalism is provided to model both system behaviour, in mapping a set of symptoms to a set of treatment options and deliberative governance strictures so that formal reasoning techniques, such as deduction, induction or abduction, can be applied to analyse the meta-control of the system. Although a detailed description of the Situation Calculus is outside the scope of this paper a full specification and modern interpretation can be found in [27]. Briefly stated, the Situation Calculus is based on actions. A situation is an action history emanating from an initial situation, defined by a set of function values called fluents. Successive situations are defined by effect axioms, for the action, on the fluents. Successor state axioms together with action precondition axioms give a complete representation of system behaviour. So a situation maps to its successor situation via an action, which makes a situation just the action history, of the system, commencing from the initial situation, S0.
4. Neptune An authoring environment, Neptune [24] has been developed that can facilitate the deployment of the Situation Calculus that forms the basis of a self-governing decision model. Whilst discussion of Neptune is out of the context of this paper, what follows is a brief discussion regarding its principal features. Neptune produces an object form of logical connectives that can be inspected, modified and deliberated upon at runtime. The logical statements that constitute an action history, or situation within the Situation Calculus, have been shown [28] to give a suitable for representation by Neptune. The resulting Neptune object encapsulates the logic and assignments expressed within the script in object notation, allowing it to be inspected, modified, recompiled, and re-evaluated at runtime. Neptune allows the modification and enhancement of the decision process during any point in its lifetime, allowing a decision model to adapt after being deployed. Such adaptation requires co-ordination. The decision process itself acts as a software agent within a grid based architecture designed to execute Neptune objects at runtime, called the Cloud Framework [24]. The Clouds concept is conceived as a system with fluid and flexible boundaries that can interact and merge with similar system architectures. Fig. 3, highlights the architectural basis of the Cloud Framework.
A Cloud can be thought of as a federation of services and resources controlled by the system controller and discovered through the system space. The system space provides persistent data storage for service registration and state information giving the means to coordinate the application service activities. The system controller controls access to and from the individual services and resources within a Cloud. It brokers requests to the system based on system status and governance rules, in Neptune objects, derived from the logical normative deliberative process. The system controller acts as an interface to the Cloud. It can function in two roles, either as an abstraction that inspects calls between the system space and services, or as a monitor that analyses the state information stored within the system space. In the current research prototype the Cloud environment (Fig. 4) produces an interactive dialogue in which the clinician enters the clinical data and is given one or more recommended treatments. At this stage of development we are looking at two approaches to critiquing the recommended outcomes. Firstly, by using a critiquing user interface [29] where the clinician enters the data and the proposed treatment and the system returns with a recommended treatment. Secondly, where ‘‘borderline’’ or difficult treatment cases are explored using more than one set of clinical guidelines to see if they converge or diverge in their recommendations. This is a similar approach to voting systems used in safety critical systems [30]. Critiquing at the user interface involves guidance by one knowledge base whereas the second form of critiquing requires the use of multiple and different knowledge bases. The development of adaptive software in healthcare systems relies on the specification and abstraction of norms that collectively constitute a decision process as expressed logically through Situation Calculus. In addition, to allow safe re-engineering in the distributed context, the representation of such norms must be designed so that
Fig. 3. Clouds architecture.
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
Fig. 4. Clouds decision rule governance tool.
1581
ARTICLE IN PRESS 1582
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
Fig. 4. (Continued)
they can be adapted at runtime without alteration to their published interface signature to maintain modularity. As discussed previously, Neptune is well suited to such representation. The design of decision processes involves a process workflow and behavioural rules that determine the movement through the process within the model. Neptune objects include a process flow model which links the decisions within the workflow to specific behaviour defined within the Neptune scripting language, with the behaviour determining the future flow of the model. Thus, with decision logic encapsulated within a Neptune Script, changes to the structure of the model are separated from changes to its logical construction, yielding separate and abstracted decision model architectures. This high level of runtime accessibility permits the complete separation of the presentation layer with the underlying process model. As an illustrative example, Fig. 5 shows a segment of a decision process model: The processes and decisions used within the model are all defined within a Neptune script. As such they exist as separate entities without necessary interaction with each other. It is the decision process model that provides flow and order to their execution. Using this methodology, the behaviour of a decision model can be altered without changes to its underlying logical constitution: rather the change can be exhibited upon its process flow: As illustrated in Fig. 6, if the result of the ‘‘processNpi’’ decision is now under 2, the process will execute ‘‘MoveOn’’
Fig. 5. Decision process model segment.
and now ‘‘CompleteTask’’. As such, neither ‘‘processNpi’’ nor ‘‘MoveOn’’ or ‘‘CompleteTask’’ have been altered, only the decision process model. Behavioural rules collectively assemble a profile of accepted behaviour for the system they describe by associating logical conditions with a set of actions to take place upon their success or failure. In the context of medical decision support, such profiling allows formal
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
1583
//created: JBel Editor 1.1 //Author: Philip Miseldine //Description: NICE Guideline for breast cancer model
//output variables define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public
considerTamoxifen noAdjuvantTreatment chemotherapyTamoxifen chemotherapyTamoxifenProp ovarianAblation chemotherapyAlone breastRadiotherapy discussBreast breastBoost chestWallRadiotherapy levelIIIAxillary axillaryRadio
//private variables define number private sd define number private NPI //rules define rule calcNPI variables.sd = 0.2 * dataset.tumorsize + dataset.nodestatus + dataset.histological if (variables.sd <= 5.3999) variables.npi = 2 else variables.npi = 1 end if
Fig. 6. Altered decision process model.
if (varaibles.sd < 3.4) variables.npi = 3 end if end define
Fig. 7. Segment of NICE guidelines as Neptune script.
modelling of clinician concerns, introducing high level assurance for their fulfilment. In conjunction with the rule-based approach we also have a data mining interface which looks at historical patient data. Our statistician colleagues have used a neural networks approach to find patterns in breast cancer survival data [31]. The outcomes from this analysis have been fed into a rule induction package to produce a set of human-understandable rules. There are two intended usages of the data-mining interface in Clouds. Firstly, as a support for clinical governance, in that, we can compare the explicit rules from published guidelines with the induced rules and see if the published rules are being followed in practice. Secondly, we can perform ‘‘What-if ?’’ analyses so that, within the patient/clinician dialogue about treatment, a doctor can illustrate to the patient that there are other patients in the historical data with a profile similar to theirs. Thus they can discuss alternative treatments in cases where either, the decision system outcomes are ambiguous, or the patient’s situation requires a different treatment from that recommended. We are currently modelling the clinical-patient dialogue within Clouds so that we can record alternative outcomes and their reasoning. As a current example, a clinical deliberation is modelled in the Situation Calculus then directly implemented into the Neptune scripts (Fig. 7). The deliberation required for clinical governance allows the services (agents) to act autonomously within safe limits whilst the deliberation to produce a guideline-based decision is completely specified by the rule-base derived from the NICE guidelines.
5. Systems evaluation Two different experiments were used to evaluate our system’s support for autonomy namely; QoS and QoP driven self-adaptation. In this paper, we restrict our discussion to QoP as QoS will be dealt with in a later paper. A clinician using our system can have a profile of acceptable behaviour, and a preferential functionality profile. Thus, the clinician when using the system from any access point will be granted access to the resources required to enable the acceptable behaviour, in essence, the QoP concerns to be fulfilled. For example, if the clinician uses a particular decision model, and often applies a range of ‘‘What-If’’ questions upon the decision model, the system will adapt the decision model to the clinician’s concerns: define situation AllowWhatIf { if (User[‘‘Oncologist\A’’.LoggedIn) { return true; } else { return false; } } define action ApplyWhatIfs using AllowWhatIf
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
1584
{ DecisionModel m ¼ DecisionModel(User[‘‘Neptune/DecisionModel’’]); } define situation pAllyWhatIfs using AllowWhatIf { if (LocalUser.DecisionModel ¼ ¼ DecisionModel(User[‘‘Neptune/DecisionModel’’]) { return true; } else { return false; } } Thus, when a clinician logs into the system (as defined within the situational state) their local decision model is obtained from the Cloud framework with its specialisations applied. As validation, the predicted state holds when the local decision model copy equates to the remote decision model (such evaluation is determined by checking the unique IDs of both decisions models, as they should be the same). Similarly, the clinician’s environment can also produce autonomy of behaviour, and triggers for deliberation (as defined in Section 6). For example, clinicians using the system from a hospital other than their own could be exposed to the local decision models of that hospital, as well as the decision models used by their own hospital. Thus, based on the environmental Information, the execution state can be influenced.
and issues with current access to IT by clinicians and their team members. Some of these issues may be resolved by the NPFit programme. However, we have already noted above problems with cost overruns, delays and issues with clinical acceptance of NPFit and its various constituent systems. From a safety viewpoint there are several issues concerning how we maintain the validity of our rules, whether induced or derived from guidelines, as NICE guidelines are update every 5 years. Within the lifetime of the project there have been new medical developments which have been used in clinical trials. We need to ensure that our system continues to give safe recommendations after any rule updated, and the situation calculus can be used to specify and validate the dynamics of such open systems [28]. In the wider medical viewpoint we can see applications for our approach in other areas of medicine, such as the diagnosis and treatment of lymphoma which has a similar staging model to breast cancer. We are also exploring the use of self-governing rule sets in Dentistry where the system would be used to module dentistry protocols. More broadly still we are looking at the use of our approach in the general area of self-governing and autonomous systems in a wide range of settings requiring ambient intelligence. Generally in this paper we have concentrated on the system aspects of our work as these provide the theoretical underpinning to our approach. The next stage of our work is to evaluate our system in clinical practice where user issues for patients and clinicians will become the priority. Acknowledgements This project is collaboration between Liverpool John Moores University, the Christie Hospital, Manchester and the Linda McCartney Centre of the Royal Liverpool Hospital. It is funded by the EPSRC.
6. Conclusions This paper has presented a new approach to modelling medical guidelines in a computer implemented format. The whole system perspective used an agent based methodology whereby actor and service agents cooperated to produce a treatment decision based on medical evidence whilst the system adapted to its users’ demands and perceived profiles. The complexity engendered by such an approach was handled according to a separation of concerns principle. In this way, the complex interactions of system and system control are dealt with as separate aspects of the system, thus modularising the complexity and incorporating clinical governance concerns into system aspects. The resulting implementation provided a robust, agile, fault tolerant and easy to use decision support system. In addition, it provides all the functionality of currently available guideline modelling approaches. There are a number of remaining challenges to the successful deployment of the kind of system we are proposing. Practically, there are implementation problems
References [1] The 2nrich Project: http://www.cms.livjm.ac.uk/2nrich [2] England D, Taleb-Bendiab A, Miseldine P, Randles M, Murphy K. Sources of complexity in the design of healthcare systems: autonomy vs. governance. Complexity in design workshop. University of Glasgow, March 2005. [3] NICE, National Institute for Clinical Excellence, www.nice.org.uk, 2005. [4] Woolf SH, Grol R, Hutchinson A, Eccles M, Grimshaw J. Potential benefits, limitations and harms of clinical guidelines. Br Med J 1999; 318:527–30. [5] Feder G, Eccles M, Grol R, Griffiths C, Grimshaw J. Clinical guidelines: using clinical guidelines. Br Med J 1999;318:728–30. [6] Rosenberg W, McDonald A. Evidence based medicine: an approach to clinical problem-solving. Br Med J 1995;310:1122–6. [7] NPFit, National Programme for IT in the NHS, www.npfit.nhs. gov.uk, 2004. [8] PITAC—President’s Information Technology Advisory Committee, Revolutionizing health care through information technology, June 2004. [9] BBC News: http://news.bbc.co.uk/1/hi/health/4245695.stm (Accessed June, 2005).
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585 [10] Reason J. Managing the risks of organisational accidents. Ashgate, 1997. [11] Reason J. Human error. Cambridge: Cambridge University Press; 1990. [12] Overhage JM, Zhou XH, McDonald CJ. A randomized trial of ‘corollary orders to prevent errors of omission. J Am Med Inform Assoc 1997;4(5):354–75. [13] Starren J, Hripcsak G, Jordan D, Allen B, Weissman C, Clayton PD. Encoding a post-operative coronary artery by-pass surgery care plan in the Arden Syntax. Comput Biol Med 1994;24(5):411–7. [14] Shiffman RN. Representation of clinical practice guidelines in conventional and augmented decision tables. J Am Med Inform Assoc 1997;4(5):382–93. [15] Hagerty CG, Pickens D. HGML: A Hypertext Guideline Mark-up Language. In: Proceedings of annual meeting of the American Medical Informatics Association (AMIA), Los Angeles, CA, 2000. [16] Shiffmann R, Karras B. GEM: a proposal for a more comprehensive guideline document model using XML. J Am Med Inform Assoc 2000;7(5):488–98. [17] Wang D, Peleg M. Representation of clinical practice guidelines. London: Medinfo; 2001. [18] Peleg M, Boxwala A, Ogunyemi O. GLIF3: the evolution of a guideline representation format. Proc AMIA 2000:645–9. [19] Fox J, Johns N, Rahmanzadeh A, Thompson R. Proforma: a method and language for specifying clinical guidelines and protocols. In: Proceedings of medical informatics Europe. Amsterdam, 1996. [20] Fox J, Das S. Safe and sound: artificial intelligence in hazardous applications. Menlo Park, CA: American Association for Artificial Intelligence; 2000. [21] Ogunyemi O, Zeng Q, Boxwala A. Object-oriented guideline expression language (GELLO) specification. Harvard Medical School, Decisions Systems Group Technical Report DSG-TR-2002-001, 2002.
1585
[22] Reiter R. The frame problem in the situation calculus: a simple solution (sometimes) and a complete result for goal regression. In: Lifschitz V, editor. Artificial intelligence and mathematical theory of computation: papers in honor of John McCarthy. San Diego, CA: Academic Press; 1991. p. 359–80. [23] Boman M. Norms in artificial decision making. AI and Law, 1999. [24] Miseldine P. Neptune Application Development Guide, 2nrich Project. http://www.cms.livjm.ac.uk/2nrich/deliverables.asp. 2004. [25] McCarthy J. Situations, actions and causal laws. Technical Report, Stanford University, 1963. In: Minsky M, editor. Cambridge, MA: MIT Press; 1968. p. 410–7 [Reprinted in Semantic Information Processing]. [26] McCarthy J, Hayes P. Some philosophical problems from the standpoint of artificial intelligence. In: Meltzer B, Michie D, editors. Machine intelligence, vol. 4. Edinburgh, Scotland: Edinburgh University Press; 1968. p. 463–502. [27] Levesque HJ, Pirri F, Reiter R. Foundations for the situation calculus. Linko¨ping Electron Articles Comput Inform Sci 1998 http:// www.ep.liu.se/ea/cis/1998/018/. [28] Randles M, Taleb-Bendiab A, Miseldine P. A stochastic situation calculus modelling approach for autonomic middleware. In: Proceedings of PGNet. Liverpool John Moores University; 2004. [29] Gray PD, Draper SW. A unified concept of style and its place in user interface design. In: Proceedings of BCS HCI 96 conference. Cambridge: Cambridge University Press; 1996. [30] Mackie J, Sommerville I. Failures of healthcare systems. In: Proceedings of the first dependability IRC workshop, Edinburgh, UK, March 22–23, 2000. [31] Jarman I, Lisboa PJ. A comparative study of NPI and PLANN-ARD by prognostic accuracy and treatment allocation for breast cancer patients, ENRICH Deliverables, http://www.cms.livjm.ac.uk/2nrich/ deliverables2.asp, 2004.
Reliability Engineering and System Safety 91 (2006) 1576–1585 www.elsevier.com/locate/ress
A principled approach to the design of healthcare systems: Autonomy vs. governance A. Taleb-Bendiab, David England, Martin Randles, Philip Miseldine, Karen Murphy School of Computing and Mathematical Sciences, Liverpool John Moores University, Byrom St, Liverpool L3 3AF, UK Available online 19 April 2006
Abstract In this paper, we look at decision support for post-operative breast cancer care. Our main concerns are to support autonomy of decision making whilst maintaining the governance and reliability of the decision-making process. We describe the context of our work in the wider medical setting. We then present a set of decision support tools based on the situation calculus as a means of maintaining the integrity of rule bases underlying the decision-making system. The decision support system, Neptune, allows for the authoring, maintenance and delivery of decisions in a self-governing framework. Finally we discuss the implications of our work. r 2006 Elsevier Ltd. All rights reserved. Keywords: Decision support; Breast cancer care; Autonomy; Self-governing systems
1. Introduction 1.1. Evidence-based era This project on decision support for post-operative breast cancer care [1] raises a number of interdisciplinary questions in a complex and emotive area. The project is collaboration between computer scientists, statisticians and clinicians, a complex arrangement in itself. The nature of the subject involves the making of difficult decisions as clinicians and patients are faced with life and death choices. The decision support processes must therefore follow methods that promote the safety and reliability of the outputted decision whilst also maintaining system robustness and fault tolerance. Additionally from an HCI viewpoint we are also faced with supporting and not supplanting clinician’s judgments. There are also wider issues arising from the implications of our studies regarding the historical clinical data and what that might mean for future approaches to prognosis. In an earlier paper [2], an approach to process understanding, in breast cancer care, was discussed. It described how decisions on post-operative breast cancer treatment Corresponding author. Tel.: +44 151 231 2271; fax: +44 151 207 4594.
E-mail address: [email protected] (D. England). 0951-8320/$ - see front matter r 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.ress.2006.01.011
are currently governed by a set of medical guidelines including the National Institute for Clinical Evidence (NICE) guidelines [3] in which the decision process is as follows (Fig. 1): The clinician uses available data with a staging method to define the patient risk category. The risk category is then used to determine the type of treatment (T1yT6) that the patient could be offered. Medical experts are expected to make the best available decision in the circumstances. However, this becomes increasingly difficult as available medical knowledge expands. Computers and decision support system software have the capacity to handle and deal with all this information. In general computers are better than humans at managing large amounts of information and the resulting complexity. Thus, the guidelines approach has the potential to make medical practice more consistent, efficacious, safer and cost effective [4]. However, guidelines can cause benefit or harm and need to be ‘‘yrigorously developed, evidence based guidelines [to] minimise the potential harms’’. Additionally the uptake by the clinicians needs to be addressed as, in practice; guidelines are often not used [5]. The evidence-based approach to the delivery of medical care has gained wide recognition within the healthcare community, advocating that decision making should use current knowledge and clinical evidence from systematic research [6]. In breast cancer care, in particular, there are
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
T1 Input Patient Data
T2 T3
Staging Method for Risk Assessment T6
T4 T5
Fig. 1. Guideline process.
currently a number of staging methods widely used by clinicians, in particular the Nottingham and Manchester staging systems. However, there is no standard method to support clinicians’ decision-making processes as to how and when to include new evidence, and how to validate emerging local patient data patterns or other models and practices from elsewhere. This means that there is no standard way to ensure that clinicians are following accepted guidelines or deviating from them. There may be valid clinical reasons why a standard decision path is not chosen (e.g. the age or infirmity of the patient) but these decisions are not currently recorded in a standard way. In comparison computer implemented guidelines have the potential to be better used at a local level by:
improving accessibility by the clinical team, performing additional tasks such as prescription writing, warning of potential hazards, and providing alternative views of the information.
On a larger scale; systems can take on functions such as: recommendation, presentation, documentation, registration, communication, explanation, calculation and aggregation. There are many contributory factors to the complexity of designing these systems, some of which are described below:
Environment and context—The aims of national initiatives such as NPFit/PACIT [7,8] in driving down costs and errors, etc. The complexity of the context depends on the observer. So the views of the various reforming agencies almost certainly differ from those of the practitioners. The autonomy of clinicians versus the governance requirements of clinical audit and traceability to support for instance clinical governance. In any case the autonomy of action is bounded within set limits. This is a complex relationship that must be represented in any up to date implemented system. Resource limitations—staffing, drugs, radiology, etc. Again resources are bounded. The limitations of medical knowledge and how that knowledge evolves. So it must be a priority to ensure that new knowledge can quickly and easily be assimilated into the system without stopping and restarting.
1577
The co-evolution of knowledge and the needs for system validation and safety. So the system needs to evolve in a safe, reliable and predictable manner as prescribed by the governance strictures. The requirements for safe solutions and effective treatment, as part of the overall goal of engineering a reliable safety critical system. The (moving) requirements for knowledge elicitation to be used to update the decision processes. The ability of computer scientists to encode medical knowledge is limited to expert advice gained from clinicians. The limitations of data mining approaches as a means to supporting evidence-based, decision making.
Finally, there is the concern over the impact of the introduction of computer support in the decision process and the effect this may have on clinical practice. 1.2. National programmes In both the UK and US there are national initiatives to introduce greater use of IT in clinical settings. The broad aims of the NPFit and PACIT programmes are similar. They aim to streamline data processing to cut costs and reduce clinical errors. For example, it is proposed that electronic prescribing of medicines will cut costs in paperwork and reduce prescribing errors which account for a large number of patient deaths (44,000–98,000 deaths caused by all types of medical errors in the USA). Both schemes aim to introduce electronic patient records, again to cut costs of paper records and reduce errors from paperbased systems. Both systems also look to more clinical governance and audit of medical processes so that medical staff are more accountable for their actions. The UK initiative is already displaying the signs of a large project out of control with the projected costs of £6Bn rising to between £18Bn and £31Bn. The lack of user centred design is evident by a recent [9] poll showing 75% of family doctors are not certain that NPFit will ever meets its goals. The first stage of the electronic appointment systems has largely failed to meets its use targets. However, a smaller scale introduction of region-wide IT in the Wirral was more widely accepted with 90% of family surgeries and the vast number of patients accepting the system. Thus IT systems can succeed. This is important for our work, for in order to succeed, it requires a working IT health infrastructure. Furthermore the twin goals of cost and error reduction may be mutually incompatible. As Reason points out [10] organisations have processes for productivity and safety but circumstances will arise, either through unsafe acts or latent system weaknesses, which lead to organisational failure. Safety protocols may be violated in the name of efficiency or sets of latent weaknesses will line up to cause an accident. Many individual errors are the result of cognitive under-specification [11] of the user’s tasks. In this project we aim to over-specify and support
ARTICLE IN PRESS 1578
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
clinical tasks by first describing both the decision and system control processes and representing them as agentbased deliberative architectures in the situation calculus. This leads to a natural implementation in a custom designed language, Neptune that implements the situation calculus expressions within a grid based architecture called clouds. This will provide a robust means of supporting decision making and ensuring that chances to decisions protocols remain valid. Some of the sources of complexity in the design of healthcare systems are addressed. More specifically, we are interested in safe and reliable decision support for post-operative breast cancer care and the wider lessons we can learn from our experiences. Accordingly, the next Section 2 provides an overview of related work in the area of support for clinical guidelines. Section 3 then gives an overview of the formal methodology used in our approach. Whilst Section 4 shows the development process from system description to formal model to the actual implementation. This approach is evaluated in Section 5 with conclusions and future work closing the paper in Section 6. 2. Related work Clinicians and co-researchers have developed evidencebased guidelines to improve the quality of patient care, aiming to reduce some of the complexity we outlined above. Software implementations of guidelines are more likely to be used by clinicians if they provide patient specific advice during consultations [12]. The provision of such support relies upon a machine interpretable guideline model. There are a number of general features that such a guideline-based decision support model needs to. These include representation, structure, expressiveness, complexity management, knowledge acquisition and safety/reliability. For example, the Arden Syntax [13], was developed to act as a hospital ‘‘watchdog’’ monitoring clinical data values. It is a text-based programming language for encoding medical logic modules (MLMs). However, it is difficult for non-computer literate medical experts to use. Similarly augmented decision tables (ADTs) [14] have also been used, to extend the rule-based functionality of Arden, by augmenting rules with additional data such as probability and utility. However, neither the Arden Syntax nor ADTs provide support for conceptualising a multi-step guideline that evolves over time and which allows the accrual of evidence. This is why the next generation of guideline models has focussed on object-oriented, taskbased formalisms that unlike simple rule-based systems allow:
Also, they provide methods of handling complexity such as: data abstraction, data hiding and modularity. The hypertext graphic mark-up language (HGML) [15] uses XML to give a descriptive representation. Using XML elements it performs the task of identifying and connecting statements, conditions and recommendations. However, this limits the range of decision making as, for example, there is no way to encode Boolean conjunctions. In contrast the guideline elements mark-up (GEM) [16] is a descriptive XML representation with over a hundred element types making it expressive but also more complicated. There is no link between the clinical knowledge base and the location of the acquired knowledge. The system can therefore contain implied rather explicit decision-making knowledge making the updating of the decision based more complex. What we need is expressiveness of the system representation is without unnecessary complexity. The minimum features we require are: a structure to hold the patient information, the ability to make a decision and to perform actions [17]. Additionally process flow in decision making needs to be controlled by temporal sequencing, looping, multiple entry points or non-deterministic actions. GLIF [18] and Proforma [19] are based on algorithmic designs (Fig. 2) with Proforma having a safety focus based on the red representation language (R2L). Proforma deliberately tries to support expressiveness by a minimal set of modelling constructs. It supports four tasks: actions, compound plans, decisions and enquiries. All tasks inherit attributes describing: goals, control flow, preconditions and post conditions. Safety in computer implemented guideline systems is a critical responsibility. Safety is more likely to be supported in systems where [20]:
there is a recognised software design paradigm being used, knowledge and decision logic are separated, a simple tool kit is used, there is a minimal feature, set expressive enough to encode guidelines in a simple manner, a decision-making process can be followed, and clinician knowledge can be used and the decision overridden.
GLIF stresses the importance of sharing guidelines among different institutions and software systems. Its
COMMIT ALTERNATIVES
the explicit modelling of alternative pathways, flow control, and a visual representation of plans and the organisation of tasks within them.
ACTION
SITUATION
GOALS
ARGUMENTS
DATABASE: REASONING AND BELIEFS Fig. 2. Algorithmic decision process.
PLAN
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
expression language was originally based on the Arden syntax but more recently the object-oriented language GELLO [21] is being used. Both Proforma and GLIF are very expressive and are capable of implementing a broad range of guidelines. This expressiveness, however, means medical experts may not necessarily able to author guidelines without substantial extra training. Also, in a similar way to GEM, there is no way of connecting descriptive text with related implemented guideline content. This makes tracking changes and ramifications very difficult in a guideline database. Finally, the structure of GLIF and Proforma is rigid. The limits the clinicians input it terms of updating guidelines when required and over-riding system decision given particular patient knowledge. This is where the methodology suggested in this paper differs from the standard approaches considered so far. The guideline implementation process is seen as a complete system comprising of both the decision-making process and the self-governance, including clinical governance, of the system itself. We use an agent-based architecture as the basis of: requesting a decision, making a decision, providing the decision, logging the process and providing overall system management. This allows the intrinsic complexity of guideline implementation and management to be modularised. In this way, both quality of service (QoS) and quality of process (QoP) can be assessed within an adaptable, self-contained system. 3. Methodology In our approach, we use the situation calculus [22] for decision knowledge modelling and Neptune system for guideline authoring and decision-making support. This gives us a route from; narrative guidelines derived from our clinical partners, to verifiably correct logical models, and hence on to the enactment of clinical decisions in Neptune. In a multidisciplinary project, this project started by understanding the current decision-making practices as a prelude to systems’ implementations. This will be evaluated using a set of small-scale controlled trials. The proposed method, unlike traditional decision-making techniques, will provide breast cancer clinicians and patients with a more flexible decision-making framework, adaptive to their decision practices. It will also allow for evolution of decision models, decision resources (data) and users concerns. This novel approach will provide important insights into the development of an integrated decision support infrastructure for high assurance decision activities, which will directly contribute to one of the NHS R&D high priority area of ‘‘Medical Devices Directives for cancer patient care’’. 3.1. The process To take a new approach to modelling, validation and enactment of clinical guidelines, our work uses techniques from distributed Artificial Intelligence. In such an ap-
1579
proach, a given treatment recommendation decision tree is conceived of as a human/artificial, multi-agent system. Here, the actions of the agents are governed by a set of system norms, each of which is a set of rules that enable or disable a given desirable or undesirable system behaviour, respectively. Each actor agent, in the system, brings their own epistemic state and behavioural norms to the multiagent environment. So the system norms comprise of, at least, the agents’ shared ontology. Above this the agents retain there own autonomy separate from the shared system’s demands of governance (i.e. maintaining the integrity of the rules). Thus, the agent is autonomous but this is always bounded by the governance strictures enforced on the system via the normative environment. In this way, there is a flux between the self-governance of the system and the bounded autonomy of the local agents. The system norms to facilitate self-governance may relate to the control of the system in maintaining availability, fault tolerance, adaptability, etc. for QoS, or they may be concerned with the output results such as clinical guideline compliance for QoP. In any event the goal is complete system governance within safe limits, encompassing clinical governance. It is a complex process, in itself, to produce safety critical systems. However, the need to permit variability and variety of clinicians’ usage, adds another level of complexity. The autonomy that needs to be retained by the clinician is tempered by the constraints of clinical governance. Thus, if the system is required to take control of management functions the autonomy of the system’s agents is compromised. However, the agents are autonomous, rational and social so computational economy is best served by the agents following the clinical norms. Norms arise from a social situation in that they involve providing rules for a community of more than one individual [23]. The norms can be associated with producing decisions, as a practical application, or with the governance of the system and clinical processes. 3.2. Formal modelling using the situation calculus The following section introduces the Situation Calculus, as a first-order logical method of handling dynamical systems that can then be verifiably implemented in our authoring system, Neptune [24]. The Situation Calculus [25] is especially suited to the analysis of dynamic systems because there is no need for the prior enumeration of the state space so unexpected external events can be accommodated. The frame problem [26] initially limited the applicability of the approach. However, a solution for deterministic actions [22] gave automatic frame axiom representation with effect axioms using the concept of a successor state. This calculus provides an excellent logical implementation framework for autonomous software agents that sense, deliberate and act in unpredictable environments. It takes higher level cognition as a determiner for agent behaviour, modelling agent beliefs and their consequences.
ARTICLE IN PRESS 1580
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
These beliefs include: what is true in the environment, the agents’ knowledge about actions performed by themselves, other agents and the environment, the conditions under which an action can be performed and about the outcomes of its perceptions. These beliefs are modelled in the form of logical sentences conditioning behaviour and how deliberation can lead to action. What-if scenarios can be modelled with branching time-lines and counterfactual reasoning. Thus, a formalism is provided to model both system behaviour, in mapping a set of symptoms to a set of treatment options and deliberative governance strictures so that formal reasoning techniques, such as deduction, induction or abduction, can be applied to analyse the meta-control of the system. Although a detailed description of the Situation Calculus is outside the scope of this paper a full specification and modern interpretation can be found in [27]. Briefly stated, the Situation Calculus is based on actions. A situation is an action history emanating from an initial situation, defined by a set of function values called fluents. Successive situations are defined by effect axioms, for the action, on the fluents. Successor state axioms together with action precondition axioms give a complete representation of system behaviour. So a situation maps to its successor situation via an action, which makes a situation just the action history, of the system, commencing from the initial situation, S0.
4. Neptune An authoring environment, Neptune [24] has been developed that can facilitate the deployment of the Situation Calculus that forms the basis of a self-governing decision model. Whilst discussion of Neptune is out of the context of this paper, what follows is a brief discussion regarding its principal features. Neptune produces an object form of logical connectives that can be inspected, modified and deliberated upon at runtime. The logical statements that constitute an action history, or situation within the Situation Calculus, have been shown [28] to give a suitable for representation by Neptune. The resulting Neptune object encapsulates the logic and assignments expressed within the script in object notation, allowing it to be inspected, modified, recompiled, and re-evaluated at runtime. Neptune allows the modification and enhancement of the decision process during any point in its lifetime, allowing a decision model to adapt after being deployed. Such adaptation requires co-ordination. The decision process itself acts as a software agent within a grid based architecture designed to execute Neptune objects at runtime, called the Cloud Framework [24]. The Clouds concept is conceived as a system with fluid and flexible boundaries that can interact and merge with similar system architectures. Fig. 3, highlights the architectural basis of the Cloud Framework.
A Cloud can be thought of as a federation of services and resources controlled by the system controller and discovered through the system space. The system space provides persistent data storage for service registration and state information giving the means to coordinate the application service activities. The system controller controls access to and from the individual services and resources within a Cloud. It brokers requests to the system based on system status and governance rules, in Neptune objects, derived from the logical normative deliberative process. The system controller acts as an interface to the Cloud. It can function in two roles, either as an abstraction that inspects calls between the system space and services, or as a monitor that analyses the state information stored within the system space. In the current research prototype the Cloud environment (Fig. 4) produces an interactive dialogue in which the clinician enters the clinical data and is given one or more recommended treatments. At this stage of development we are looking at two approaches to critiquing the recommended outcomes. Firstly, by using a critiquing user interface [29] where the clinician enters the data and the proposed treatment and the system returns with a recommended treatment. Secondly, where ‘‘borderline’’ or difficult treatment cases are explored using more than one set of clinical guidelines to see if they converge or diverge in their recommendations. This is a similar approach to voting systems used in safety critical systems [30]. Critiquing at the user interface involves guidance by one knowledge base whereas the second form of critiquing requires the use of multiple and different knowledge bases. The development of adaptive software in healthcare systems relies on the specification and abstraction of norms that collectively constitute a decision process as expressed logically through Situation Calculus. In addition, to allow safe re-engineering in the distributed context, the representation of such norms must be designed so that
Fig. 3. Clouds architecture.
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
Fig. 4. Clouds decision rule governance tool.
1581
ARTICLE IN PRESS 1582
A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
Fig. 4. (Continued)
they can be adapted at runtime without alteration to their published interface signature to maintain modularity. As discussed previously, Neptune is well suited to such representation. The design of decision processes involves a process workflow and behavioural rules that determine the movement through the process within the model. Neptune objects include a process flow model which links the decisions within the workflow to specific behaviour defined within the Neptune scripting language, with the behaviour determining the future flow of the model. Thus, with decision logic encapsulated within a Neptune Script, changes to the structure of the model are separated from changes to its logical construction, yielding separate and abstracted decision model architectures. This high level of runtime accessibility permits the complete separation of the presentation layer with the underlying process model. As an illustrative example, Fig. 5 shows a segment of a decision process model: The processes and decisions used within the model are all defined within a Neptune script. As such they exist as separate entities without necessary interaction with each other. It is the decision process model that provides flow and order to their execution. Using this methodology, the behaviour of a decision model can be altered without changes to its underlying logical constitution: rather the change can be exhibited upon its process flow: As illustrated in Fig. 6, if the result of the ‘‘processNpi’’ decision is now under 2, the process will execute ‘‘MoveOn’’
Fig. 5. Decision process model segment.
and now ‘‘CompleteTask’’. As such, neither ‘‘processNpi’’ nor ‘‘MoveOn’’ or ‘‘CompleteTask’’ have been altered, only the decision process model. Behavioural rules collectively assemble a profile of accepted behaviour for the system they describe by associating logical conditions with a set of actions to take place upon their success or failure. In the context of medical decision support, such profiling allows formal
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
1583
//created: JBel Editor 1.1 //Author: Philip Miseldine //Description: NICE Guideline for breast cancer model
//output variables define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public define text public
considerTamoxifen noAdjuvantTreatment chemotherapyTamoxifen chemotherapyTamoxifenProp ovarianAblation chemotherapyAlone breastRadiotherapy discussBreast breastBoost chestWallRadiotherapy levelIIIAxillary axillaryRadio
//private variables define number private sd define number private NPI //rules define rule calcNPI variables.sd = 0.2 * dataset.tumorsize + dataset.nodestatus + dataset.histological if (variables.sd <= 5.3999) variables.npi = 2 else variables.npi = 1 end if
Fig. 6. Altered decision process model.
if (varaibles.sd < 3.4) variables.npi = 3 end if end define
Fig. 7. Segment of NICE guidelines as Neptune script.
modelling of clinician concerns, introducing high level assurance for their fulfilment. In conjunction with the rule-based approach we also have a data mining interface which looks at historical patient data. Our statistician colleagues have used a neural networks approach to find patterns in breast cancer survival data [31]. The outcomes from this analysis have been fed into a rule induction package to produce a set of human-understandable rules. There are two intended usages of the data-mining interface in Clouds. Firstly, as a support for clinical governance, in that, we can compare the explicit rules from published guidelines with the induced rules and see if the published rules are being followed in practice. Secondly, we can perform ‘‘What-if ?’’ analyses so that, within the patient/clinician dialogue about treatment, a doctor can illustrate to the patient that there are other patients in the historical data with a profile similar to theirs. Thus they can discuss alternative treatments in cases where either, the decision system outcomes are ambiguous, or the patient’s situation requires a different treatment from that recommended. We are currently modelling the clinical-patient dialogue within Clouds so that we can record alternative outcomes and their reasoning. As a current example, a clinical deliberation is modelled in the Situation Calculus then directly implemented into the Neptune scripts (Fig. 7). The deliberation required for clinical governance allows the services (agents) to act autonomously within safe limits whilst the deliberation to produce a guideline-based decision is completely specified by the rule-base derived from the NICE guidelines.
5. Systems evaluation Two different experiments were used to evaluate our system’s support for autonomy namely; QoS and QoP driven self-adaptation. In this paper, we restrict our discussion to QoP as QoS will be dealt with in a later paper. A clinician using our system can have a profile of acceptable behaviour, and a preferential functionality profile. Thus, the clinician when using the system from any access point will be granted access to the resources required to enable the acceptable behaviour, in essence, the QoP concerns to be fulfilled. For example, if the clinician uses a particular decision model, and often applies a range of ‘‘What-If’’ questions upon the decision model, the system will adapt the decision model to the clinician’s concerns: define situation AllowWhatIf { if (User[‘‘Oncologist\A’’.LoggedIn) { return true; } else { return false; } } define action ApplyWhatIfs using AllowWhatIf
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585
1584
{ DecisionModel m ¼ DecisionModel(User[‘‘Neptune/DecisionModel’’]); } define situation pAllyWhatIfs using AllowWhatIf { if (LocalUser.DecisionModel ¼ ¼ DecisionModel(User[‘‘Neptune/DecisionModel’’]) { return true; } else { return false; } } Thus, when a clinician logs into the system (as defined within the situational state) their local decision model is obtained from the Cloud framework with its specialisations applied. As validation, the predicted state holds when the local decision model copy equates to the remote decision model (such evaluation is determined by checking the unique IDs of both decisions models, as they should be the same). Similarly, the clinician’s environment can also produce autonomy of behaviour, and triggers for deliberation (as defined in Section 6). For example, clinicians using the system from a hospital other than their own could be exposed to the local decision models of that hospital, as well as the decision models used by their own hospital. Thus, based on the environmental Information, the execution state can be influenced.
and issues with current access to IT by clinicians and their team members. Some of these issues may be resolved by the NPFit programme. However, we have already noted above problems with cost overruns, delays and issues with clinical acceptance of NPFit and its various constituent systems. From a safety viewpoint there are several issues concerning how we maintain the validity of our rules, whether induced or derived from guidelines, as NICE guidelines are update every 5 years. Within the lifetime of the project there have been new medical developments which have been used in clinical trials. We need to ensure that our system continues to give safe recommendations after any rule updated, and the situation calculus can be used to specify and validate the dynamics of such open systems [28]. In the wider medical viewpoint we can see applications for our approach in other areas of medicine, such as the diagnosis and treatment of lymphoma which has a similar staging model to breast cancer. We are also exploring the use of self-governing rule sets in Dentistry where the system would be used to module dentistry protocols. More broadly still we are looking at the use of our approach in the general area of self-governing and autonomous systems in a wide range of settings requiring ambient intelligence. Generally in this paper we have concentrated on the system aspects of our work as these provide the theoretical underpinning to our approach. The next stage of our work is to evaluate our system in clinical practice where user issues for patients and clinicians will become the priority. Acknowledgements This project is collaboration between Liverpool John Moores University, the Christie Hospital, Manchester and the Linda McCartney Centre of the Royal Liverpool Hospital. It is funded by the EPSRC.
6. Conclusions This paper has presented a new approach to modelling medical guidelines in a computer implemented format. The whole system perspective used an agent based methodology whereby actor and service agents cooperated to produce a treatment decision based on medical evidence whilst the system adapted to its users’ demands and perceived profiles. The complexity engendered by such an approach was handled according to a separation of concerns principle. In this way, the complex interactions of system and system control are dealt with as separate aspects of the system, thus modularising the complexity and incorporating clinical governance concerns into system aspects. The resulting implementation provided a robust, agile, fault tolerant and easy to use decision support system. In addition, it provides all the functionality of currently available guideline modelling approaches. There are a number of remaining challenges to the successful deployment of the kind of system we are proposing. Practically, there are implementation problems
References [1] The 2nrich Project: http://www.cms.livjm.ac.uk/2nrich [2] England D, Taleb-Bendiab A, Miseldine P, Randles M, Murphy K. Sources of complexity in the design of healthcare systems: autonomy vs. governance. Complexity in design workshop. University of Glasgow, March 2005. [3] NICE, National Institute for Clinical Excellence, www.nice.org.uk, 2005. [4] Woolf SH, Grol R, Hutchinson A, Eccles M, Grimshaw J. Potential benefits, limitations and harms of clinical guidelines. Br Med J 1999; 318:527–30. [5] Feder G, Eccles M, Grol R, Griffiths C, Grimshaw J. Clinical guidelines: using clinical guidelines. Br Med J 1999;318:728–30. [6] Rosenberg W, McDonald A. Evidence based medicine: an approach to clinical problem-solving. Br Med J 1995;310:1122–6. [7] NPFit, National Programme for IT in the NHS, www.npfit.nhs. gov.uk, 2004. [8] PITAC—President’s Information Technology Advisory Committee, Revolutionizing health care through information technology, June 2004. [9] BBC News: http://news.bbc.co.uk/1/hi/health/4245695.stm (Accessed June, 2005).
ARTICLE IN PRESS A. Taleb-Bendiab et al. / Reliability Engineering and System Safety 91 (2006) 1576–1585 [10] Reason J. Managing the risks of organisational accidents. Ashgate, 1997. [11] Reason J. Human error. Cambridge: Cambridge University Press; 1990. [12] Overhage JM, Zhou XH, McDonald CJ. A randomized trial of ‘corollary orders to prevent errors of omission. J Am Med Inform Assoc 1997;4(5):354–75. [13] Starren J, Hripcsak G, Jordan D, Allen B, Weissman C, Clayton PD. Encoding a post-operative coronary artery by-pass surgery care plan in the Arden Syntax. Comput Biol Med 1994;24(5):411–7. [14] Shiffman RN. Representation of clinical practice guidelines in conventional and augmented decision tables. J Am Med Inform Assoc 1997;4(5):382–93. [15] Hagerty CG, Pickens D. HGML: A Hypertext Guideline Mark-up Language. In: Proceedings of annual meeting of the American Medical Informatics Association (AMIA), Los Angeles, CA, 2000. [16] Shiffmann R, Karras B. GEM: a proposal for a more comprehensive guideline document model using XML. J Am Med Inform Assoc 2000;7(5):488–98. [17] Wang D, Peleg M. Representation of clinical practice guidelines. London: Medinfo; 2001. [18] Peleg M, Boxwala A, Ogunyemi O. GLIF3: the evolution of a guideline representation format. Proc AMIA 2000:645–9. [19] Fox J, Johns N, Rahmanzadeh A, Thompson R. Proforma: a method and language for specifying clinical guidelines and protocols. In: Proceedings of medical informatics Europe. Amsterdam, 1996. [20] Fox J, Das S. Safe and sound: artificial intelligence in hazardous applications. Menlo Park, CA: American Association for Artificial Intelligence; 2000. [21] Ogunyemi O, Zeng Q, Boxwala A. Object-oriented guideline expression language (GELLO) specification. Harvard Medical School, Decisions Systems Group Technical Report DSG-TR-2002-001, 2002.
1585
[22] Reiter R. The frame problem in the situation calculus: a simple solution (sometimes) and a complete result for goal regression. In: Lifschitz V, editor. Artificial intelligence and mathematical theory of computation: papers in honor of John McCarthy. San Diego, CA: Academic Press; 1991. p. 359–80. [23] Boman M. Norms in artificial decision making. AI and Law, 1999. [24] Miseldine P. Neptune Application Development Guide, 2nrich Project. http://www.cms.livjm.ac.uk/2nrich/deliverables.asp. 2004. [25] McCarthy J. Situations, actions and causal laws. Technical Report, Stanford University, 1963. In: Minsky M, editor. Cambridge, MA: MIT Press; 1968. p. 410–7 [Reprinted in Semantic Information Processing]. [26] McCarthy J, Hayes P. Some philosophical problems from the standpoint of artificial intelligence. In: Meltzer B, Michie D, editors. Machine intelligence, vol. 4. Edinburgh, Scotland: Edinburgh University Press; 1968. p. 463–502. [27] Levesque HJ, Pirri F, Reiter R. Foundations for the situation calculus. Linko¨ping Electron Articles Comput Inform Sci 1998 http:// www.ep.liu.se/ea/cis/1998/018/. [28] Randles M, Taleb-Bendiab A, Miseldine P. A stochastic situation calculus modelling approach for autonomic middleware. In: Proceedings of PGNet. Liverpool John Moores University; 2004. [29] Gray PD, Draper SW. A unified concept of style and its place in user interface design. In: Proceedings of BCS HCI 96 conference. Cambridge: Cambridge University Press; 1996. [30] Mackie J, Sommerville I. Failures of healthcare systems. In: Proceedings of the first dependability IRC workshop, Edinburgh, UK, March 22–23, 2000. [31] Jarman I, Lisboa PJ. A comparative study of NPI and PLANN-ARD by prognostic accuracy and treatment allocation for breast cancer patients, ENRICH Deliverables, http://www.cms.livjm.ac.uk/2nrich/ deliverables2.asp, 2004.