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 jf@acl.icnet.uk
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
5
Figure 1: The domino model of the clinical process
6
F
i
Medical g
u
procedures
r
e
3
:
T
h
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 situationspecific 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.