PROforma: a general technology for clinical decision support systems John Fox, Nicky Johns, Ali Rahmanzadeh, Richard Thomson Imperial Cancer Research Fund, Lincoln’s Inn Fields, London, WC2A 3PX, UK tel +44 171 269 3624 email
[email protected]
Abstract: The need for flexible and well understood knowledge representations which are capable of capturing clinical guidelines and protocols for decision support systems is widely recognised. The PROforma method for specifying clinical guidelines and protocols comprises a graphical notation for their design, and a formal knowledge representation language to enable them to be executed by a computer to support the management of medical procedures and clinical decision making. PROforma technology consists of a graphical knowledge editor for the creation of guidelines, and an enactment engine for testing and executing them. This paper provides an overview of the motivation and structure of PROforma, and illustrates its use in the development of clinical applications.
Keywords: Protocol-based care, decision support systems, safety, knowledge representation, knowledge based systems.
1. Introduction It is widely believed that the practical potential of clinical decision support systems and electronic clinical guidelines will only be achieved when the medical informatics community adopts standard languages for representing medical knowledge and clinical procedures. Attempts to achieve this include the "Arden syntax", a Pascal-like language which was proposed as a standard format in which medical knowledge can be described as Medical Logic Modules and embedded and reused in applications. Such standardisation efforts as the Arden Syntax are important, but proposals to date have had their shortcomings. For example, as Musen et al note [1], the developers of the Arden syntax themselves recognise that “this new standard has significant limitations: the language currently supports only atomic data types, lacks a defined semantics for making temporal comparisons or for performing data abstraction, and provides no principled way to represent clinical guidelines that are more complex than individual situation-action rules”. PROforma is being developed to address these limitations and to satisfy a number of additional requirements including clinical generality, medical expressiveness and operational flexibility.
2. Foundations of the PROforma language: the domino model The PROforma language is based on a generalised model of the clinical care process: the “domino model”. This model (figure 1) presents an abstract view of the processes of decision making and task management carried out during the execution of a clinical procedure. The nodes in the domino represent concepts, and the arrows represent inference processes. PROforma technology supports data-structures to represent the former and automated inference mechanisms to represent the latter.
1
Medical problems 2
Alternative solutions
Clinical actions
Patient record 4
3
Pros and cons
6
5
Medical procedures
Figure 1: The domino model of the clinical process
Let us consider an example to demonstrate use of the model. Suppose a statement is added to a patient record that the person in question has lost weight, and that this appears to be abnormal (it has occurred rapidly with no obvious explanation, such as dieting). A clinician would establish that this represents a clinical problem, and would obviously wish to diagnose its cause. This recognition process is represented by arrow (1) in figure 1: this represents a logical process which allows a software system to emulate the clinical reasoning involved. Using general medical knowledge, the computer may now deduce that possible causes of weight loss include, say, cancer and peptic ulcer, and record these as alternative solutions for the diagnosis problem - represented by arrow (2). Using specific information from the patient record (e.g. the patient is elderly) and general knowledge about the kinds of information which are relevant in making diagnosis decisions (e.g facts about physiology or statistical information), arguments for and against each alternative diagnosis can be constructed (3). General forms of diagnostic argument include "any condition which we know can cause the presenting problem is a possible diagnosis" or "when looking for arguments in favour of a disease consider any symptoms or signs in the patient record which are known to be frequently or rarely associated with each hypothetical disease". At some point, enough information may be available about the patient for the system to recommend taking the decision to commit to one diagnosis candidate (4).
Suppose it is decided that the patient is suffering from cancer. The conclusion is then added to the patient record. Commitment to a diagnosis results in another problem (again, arrow 1): how to treat the cancer ? As before, a set of candidate solutions is inferred from medical knowledge (2), though this time the candidates are not alternative diagnoses but medical procedures, such as chemotherapy, radiotherapy or surgery. Once again, the pros and cons of these alternatives are argued in respect of the current patient (3) and, in due course, the system proposes another decision, in this case to commit to a particular therapeutic procedure (5). Execution of clinical procedures often involves a number of steps. For example, when a cancer patient has chemotherapy it is normal to obtain various baseline measurements, such as his white blood count, and to administer several cycles of chemotherapy, usually some days or weeks apart. During each cycle the effects of treatment are monitored, and this is continued for some time following therapy. Typically, these tasks and the specific actions (like taking blood samples and giving medication) will need to be scheduled in a particular order and/or at particular times. This scheduling process (6) must be carried out using general knowledge of temporal and logical constraints, and situation-specific factors such as the patient's well-being and the availability of resources. Some tasks will be obligatory, some optional and some dependent on decisions reached if new problems arise or particular events occur. PROforma technology offers the necessary formalisms and software tools for designing systems which can carry out the kinds of reasoning described in this example, and for creating and maintaining the required data structures. 3. Designing a clinical procedure with PROforma Three kinds of knowledge are required to build a PROforma application: patient specific knowledge (personal details, problems, symptoms, current medications etc.),
general medical knowledge (of diseases, symptoms, tests, drugs), and knowledge of medical procedures (what should be done when). PROforma is primarily focused on the last type of knowledge; our intention is that it should be able to accommodate different medical knowledge models and specific patient data models. Creating a PROforma application (e.g. a computerised clinical guideline or protocol) is a two-step process. In step 1, a high level description of the guideline is created using a graphical design package. (The source is typically a published document which sets out the guideline, ideally from an authoritative body.) The resulting graphical network shows the main clinical tasks required in an easily understood form, including their logical and temporal interrelationships. In step 2, again using the graphical editor, the details of each of the clinical tasks involved in the guideline are defined. 3.1. Step 1: graphical representation of the high level structure of a guideline PROforma applications are designed to provide support for a comprehensive range of clinical tasks, such as decision making, scheduling of actions over time, reminders for patient data collection, monitoring adverse events and so forth. The top level structure in PROforma is the task: PROforma allows the specification of clinical guidelines and protocols in terms of tasks and collections of tasks. PROforma supports four basic sub-classes of task, as shown in figure 2.
Task subclasses
Plan
Decision
Action
Enquiry
Figure 2: The PROforma task ontology
•
A plan is the basic building block of a guideline, and may contain any number of tasks of any type, including other plans, usually with an ordering imposed to reflect
temporal, logical, resource or other constraints, which need to be carried out to achieve a clinical objective. We usually use the words protocol or guideline to mean a “top level” plan i.e. the container for all other guideline tasks. •
A decision, such as a diagnosis, includes a set of options, a set of argument rules which determine which of the options should be chosen according to current data values, and “commitment rules” which determine when the decision should be taken.
•
An action is a procedure linked to a clinical process which has to be carried out, such as administering an injection.
•
An enquiry is a request for an item of information which is needed in order to complete a procedure or take a decision. The specification of an enquiry includes a description of the information required (e.g. a lab. result) and a method for getting it (e.g. by a query on a local patient record or a remote laboratory database).
Starting from the available knowledge sources, an application designer typically develops a graphical network to summarise the decisions, actions and other tasks recommended by the guideline. Figure 3 shows a view of the graphical editor which has been developed for designing (and implementing) PROforma applications.
Figure 3: A view of the PROforma editor. Graphical tools are provided for laying out protocols in terms of four sub-classes of task: decisions (circles); plans (round rectangles); actions (square rectangles) and enquiries (diamonds). Arrows represent scheduling constraints. The rear window shows a couple of the component tasks of an IBS (irritable bowel syndrome) guideline for use in primary care; the front window shows task decomposition for a plan involving the initial assessment of a patient.
The graphical notation provides an intermediate representation between an informal description of the protocol or guideline (such as a conventional protocol document) and a machine executable knowledge base. The notation provides a succinct and natural summary which can be understood by medical specialists, and also helps to guide the detailed specification of the tasks by a programmer. In Step 2 of the PROforma method, the detailed clinical knowledge and other information required to populate the task network is added. 3.2. Step 2: Populating task templates All clinical tasks are different, but they can be modelled in terms of classes which have a common, generic structure. All protocols (plans), for example, have eligibility
conditions (preconditions) and conditions under which the protocol should be abandoned (abort conditions). Decisions, actions and enquiries can similarly be modelled as generic tasks. PROforma provides a standard attribute-value template, predefined for each class of task, to support the guideline definition process. Templates guide the application designer in formalising the medical knowledge required for each component task of a guideline or protocol. Each of the four sub-classes of PROforma task has a group of specific attributes which distinguish them from tasks of other types, but each also inherits a number of attributes from the general class “tasks”. For example, every task has a description, a title and preconditions, but only tasks of type action have a procedure, and only tasks of type decision have candidates. When a collection of tasks is enacted by the PROforma Engine, task attributes determine how and when each task will be processed by the engine. Table 1, as an example, shows the distinguishing attributes of decision tasks.
Attribute
Description
Candidates Arguments Commitment rules
The candidate set of decision options (hypotheses, actions). Rules defining “pros and cons” of different candidates. Rules based on arguments for committing to a candidate i.e. taking a decision. Any information sources required. Information essential for commitment of decision.
Sources Mandatory information
Table 1: Distinguishing attributes of decision tasks
From table 1 we see that all decisions (whether diagnostic decisions, therapy decisions, prescribing decisions, referral decisions, etc.) must have a set of options (candidates); they all have information sources that are relevant for selecting between the options, and rules of argument to establish preferences among the options and commitment rules.
Figure 4 below illustrates populating the decision task template in the PROforma editor.
Figure 4: Populating a task template in the PROforma editor. Here, decision task-specific attributes for part of an IBS (Irritable Bowel Syndrome) guideline are being defined. Arguments have been entered to support the decision candidate 'IBS'. The + radio button is selected to indicate a supporting argument. ++ indicates a confirming argument; indicates a diminishing argument, -- indicates an excluding argument.
4. Process enactment by the PROforma Engine The purpose of the PROforma engine is to enact the tasks specified by a guideline or protocol, that is to say it issues requests for action, prompts for information, offers suggestions for decisions, and generally assists a user to comply with the protocol in line with medical, procedural and other requirements. When the engine enacts a protocol, each task in it is "created" as required as a runtime instance with current time-stamps and other relevant information. The engine initiates tasks according to their scheduling constraints, preconditions etc., and sends messages to notify the user that tasks have been activated, provide information of decisions which need
to be made, request data or actions to be carried out etc. Figure 5 shows the engine running a primary care guideline for the management of dyspepsia.1 The user interface shown here is the default interface provided by the software. This would normally be linked to a separate and appropriately tailored application-specific GUI, as in the asthma example below (figure 6). Linking the enactment system to an existing patient record system would provide the interface familiar to clinical staff, as well as the extra functionality offered by decision support. The engine functions reactively, i.e. it responds to messages from external sources (e.g. notification of commands from a user interface, updates to the patient record, completion of time-outs etc.). Any arrival of new data will normally have repercussions throughout the current protocol (e.g. decisions which may now be taken, tasks which may now be started, etc.). The engine’s response to the arrival of a message is to propagate all these effects forward until no more changes can be made.
1
The dyspepsia and IBS primary care guidelines illustrated in this paper were developed in collaboration with Dr. Colin Lyons and Dr. Peter Wilson of North End Medical Centre, London.
Figure 5: the default interface of the enactment engine, showing the hierarchical structure of a guideline for the management of dyspepsia (left), a legend indicating the types of task and colour coding for task states (inset) and a report for a selected task (right).
5. An example application PROforma has also been designed to support construction of application-specific user interfaces. For example, a decision support system for the management of acute asthma in adults has been developed (figure 6), based on a best-practice guideline published by the British Thoracic Society.
Figure 6: A user display from a computerised guideline decision support system, in this case for the management of acute asthma in adults in a hospital accident and emergency department.
The workflow display shown in figure 6 can be used passively, to summarise and remind clinical staff of the procedures that need to be carried out when managing a patient with an acute asthma attack, or actively, to assist in the correct and timely enactment of specific clinical tasks. In the latter mode the system may prompt users for clinical actions which need to be carried out (taking into account temporal and other constraints), remind them of information that needs to be recorded, and advise on any decisions that need to be taken. In the example, the first task required by the guideline is a patient assessment decision (shown as a circle). The two panels on the right provide (1) an aide mémoire that lists the topics that are relevant to the assessment, and (2) a patient data entry screen. The appropriate enactment route of the procedure depends on the result of the assessment decision (mild, moderate, severe or life threatening). In the centre of the screen are two
important decisions: these are “watchdogs” which monitor the patient record in order to detect any adverse events or possible hazards that may occur. Decision support functions, which are used for the initial classification of the severity of the patient’s asthma, and the implementation of watchdogs, use a generalised decision procedure that can be used to support most types of clinical decision, whether diagnostic, therapeutic or prescribing. A range of different kinds of patient-specific advice can be provided by these functions: suggesting when a decision is needed, listings of the decision options and the information relevant to making a choice etc. A particularly crucial piece of advice to offer is whether the decision can (and should) be taken and, if so, to suggest on the basis of what is currently known, the best available option. 6. Conclusion PROforma embodies a language and a development method for specifying clinical procedures such as therapeutic guidelines and protocols. It provides a notation for formally specifying a wide range of clinical tasks, and the medical knowledge and patient data associated with clinical decision making. PROforma technology consists of a graphical knowledge editor for creating guidelines, and an enactment engine for testing and running applications. Details of parts of the work underlying the development of PROforma can be found in [2,3,4]. A fuller description of PROforma, and its use in supporting guidelinebased healthcare is available in [5, 6]. A detailed definition of the PROforma language will be published in due course.
Acknowledgements PROforma is based on a generalised model of clinical decision making and protocol management developed over a number of years by the Imperial Cancer Research Fund, London, Institut Bergonié, Bordeaux and other colleagues. PROforma is being developed within PROMPT (Protocols for Medical Procedures and Therapies), a project
supported by the EC 4th Framework Health Telematics programme (1996-8). The work is being undertaken by Imperial Cancer Research Fund in association with members of the ACTION cluster of projects. Thanks are due to Ian Herbert, Jean-Louis Renaud-Salis, Johan van der Lei and Paul Taylor for their contributions to the ideas reported in this paper.
References [1] Musen M A, Tu S W, Das A K and Shahar Y ‘A component based architecture for automation of Protocol-Directed Therapy’, in Barahona P, Stefanelli M and Wyatt J (eds) Proc. AIME95, Berlin: Springer, 1995. [2] Fox J et al ‘LEMMA: methods and architectures for logic engineering in medicine’ in J Noothoven and J P Christensen (eds) Advances in Medical Informa tics, Amsterdam: IOS Press, 1992. [3] Thomson R ‘Decision support in primary care, oncology an shared care’ in M F Laires, M J Ladeira and J P Christensen (eds) Health in the New Communications Age, Amsterdam: IOS Press, 1995. [4] Fox J, Das S K, Elsdon D and Hammond P ‘Decision making and planning by autonomous agents: an architecture for safety critical applications’ in Proc. Expert Systems 95, Cambridge University Press, 1995. [5] Fox J, Johns N, Rahmanzadeh A and Thomson R ‘The PROforma decision support engine’, PROMPT deliverable D5.1, ICRF Advanced Computation Laboratory, 1996. [6] Fox J, Johns N, Rahmanzadeh A and Thomson R 'PROMPT DESIGN: DSS/protocol support engine with integrated design and verification tools', PROMPT deliverable D5.3, ICRF Advanced Computation Laboratory, 1997.
