Back to List of Publications
Enrico Coiera
This article originally appeared in Medical informatics, 16, 4, 331-346, (1991).
Abstract. A user and dialogue modelling approach is proposed for the development of user interfaces for intelligent patient monitoring systems. Illustrative models and dialogues are developed and simple examples of user interfaces for a monitor system based upon these are presented. The user model and dialogue method is also used to evaluate some interface techniques from the literature.
In recent years there has been a significant research effort devoted to the development of patient monitoring systems which have their functionality augmented with artificial intelligence techniques. These intelligent patient monitors are intended to assist clinicians by diagnosing and tracking complex pathophysiological events over time, and perhaps even making therapeutic recommendations (e.g. Fagan (1984), Hayes-Roth (1989), Coiera (1990), Beech (1990)). Intelligent monitors promise to improve the manner in which clinicians practise medicine, especially in areas such as Intensive Care and in the Operating Room, both of which are dependent on sophisticated monitoring technology. While much work has gone into the design of the computational components of such systems, much less has been done on the design of appropriate user interfaces. This needs to be redressed, since the manner in which clinicians interact with intelligent monitors will have a great impact on their eventual utility.
A recent focus of interest in the field of human-computer interaction has been the development of user and dialogue models as a basis for the development of user-interfaces (Wahlster, 1986). This paper aims to introduce the concept of user and dialogue modelling and make an informal assessment of their potential benefit to the design of user interfaces for intelligent monitors. The paper will conclude with suggestions for further exploration of the role of user and dialogue modelling in this domain.
The computer and user can be seen as a joint cognitive system, and the emphasis of interface research in recent years has been to explore the interactions that occur within that system. The best interface designs are believed to be those that most accurately reflect the user's natural cognitive processes and structures (Jones, 1988). This perspective allows us to focus specifically on the manner in which communication occurs between human and computer. One method is to regard this communication as a dialogue between human and computer, and to try to exploit the conventions of human dialogues when designing the interface that will act as a channel for the communication (Stenton, 1987).
A dialogue is the observable two-way exchange of symbols and actions between the computer and human (Hartson, 1989). The basic type of dialogue is a sequential one, with the user engaging in a single thread of conversation with the computer, for example typing at a command line. Dialogues can however be complex, and current multitasking window systems allow users to engage in concurrent multi-threaded dialogues. Stenton (1987) and Hartson and Hix (1989) present a number of strategies for modelling such dialogues.
We can begin to develop a language with which to conduct our human-computer dialogue by performing a task analysis in the domain (e.g. task-action grammars (Howes and Payne, 1990)), and begin to extract the key tokens and token sequences that characterise interactions with the computer. An anaesthetist, for example, might have diagnosis as a task, and request his monitor to provide a summary of his patient's data over the last 24 hours. The dialogue might continue with requests to highlight specific elements of the data over a more specific time period as he hones in on events of interest. With analysis, we can begin to ascertain which linguistic elements will be contained in the dialogue, and what operations are to be performed with them.
The content of our dialogue will depend not just on what we want to say, but also on our mental model of the individual with which we are communicating. Discourse theory (Stenton, 1987) views dialogues as the means by which an individual attempts to change the mental state of another. The individual's own mental state influences the discourse, as it comprises beliefs and goals about the other's beliefs and goals. We make assumptions, for example, about another's knowledge when we talk to them. The difference in the way a doctor will describe an incident to a patient or to another colleague reflects the differences in the doctor's mental model of what each individual knows, is capable of knowing, and is interested in hearing. The types of dialogue that can occur will thus vary not just from domain to domain, but also from user to user. For complex domains of discourse then, we can tailor the form and content of our dialogue based upon different user models. The user model reflects the computer's understanding of the particular individual with whom it is carrying out its dialogue.
Factors like the environment within which the computer system will be operating, the competing sensory demands being made upon the user, and the motor skills available to the user need also to be considered in the model. In an operating theatre for example, an anaesthetist must divide his attention between patient, monitors, and surgeon, and may have his hands occupied while administering medication or adjusting the mechanics of a ventilator. Further, time constrains the type of conversation that can occur. A system that expects the anaesthetist to spend 10 minutes with it sorting out the diagnosis for a seriously hypotensive patient is ignoring the real-time constraints under which the doctor is operating. The design of an interface to enable a dialogue between anesthestist and monitor will take all these ergonomic factors into account in its user model.
One can envisage a computer system ascertaining which of several user models is most appropriate for a given exchange, and then modifying it's display techniques accordingly (Gargan, 1988). For example, the system may choose to display information at different levels of abstraction, and note the task perspective and perceptual abilities of different users. For a monitoring system in an operating room, a surgeon may want to see a quick overview of the current patient state, while an anaesthetist will want to see and manipulate information in a much more complex way.
Intelligent patient monitoring systems will initially be used in operating rooms and intensive care units, and one of their prime users will be anaesthetists. The following sections will begin to develop a user model for anaesthetists and explore some of the dialogues that may occur between an anaesthetist and an intelligent monitor system. Some of the constraints these place upon the design of an interface for the monitor will then be detailed and finally, several interface examples based upon this approach will be presented.
The identification of user tasks and their decomposition is a necessary first step in defining the dialogues that occur when a particular system is used. When we examine the roles that an anaesthetist must fulfil during an operation, a number of broad task categories can be identified:
1- Prior to commencing the anaesthetic, the anaesthetist must make an assessment of the patient, determining if the patient is at risk, and if any special precautions need to be taken.
2 - Next, he must anaesthetise the patient, commencing with an induction phase.
3 - The anaesthetist must then maintain an appropriate anaesthetic state intraoperatively.
4 - The anaesthetist must also detect and respond to abnormal intraoperative events.
The last two tasks could both be aided by an intelligent monitoring system. The problem of maintaining an appropriate anaesthetic state intraoperatively calls for sophisticated visualisation tools of patient state, and the development of aids for fine tuning the delivery of anaesthetic agents. The detection and explanation of physiological events requires sophisticated diagnostic tools and explanation facilities. Interestingly, these two tasks are carried out in parallel - one may temporarily take precedence over the other, but both must be addressed continually throughout the operation. This suggests that at least two separate dialogue streams will be active at any one time between an anaesthetist and the monitor device. The first will be concerned with maintenance of anaesthetic state, and the second will be concerned with detection and treatment of unexpected pathophysiological events.
We will now examine the second of these two active anaesthetic tasks - the detection of abnormal intraoperative events - in more detail and attempt to formalise this into a dialogue. The hope is that by expending sufficient effort characterising the dialogue, a rational development of display techniques that could support it will follow. The user model we develop will also have an influence on the way in which the dialogue is displayed. As we will see later, for example, the need of clinicians to feel that an advice giving system is reliable will be reflected in the amount of data abstraction they will tolerate in an interface display.
An intelligent monitor can assist not just with the detection but also explanation of new and potentially threatening events intraoperatively. Explanation is a critical issue in most expert systems work - justifying how a decision was reached. As many high level alarms will necessitate intervention by the clinicians, the inability to assess the basis of such an alarm would reduce its value to a clinician.
An alarm dialogue commences when an alarm is reported by the monitor (Fig 1). The anaesthetist can then choose to act upon it or ignore it, based upon the current clinical context. For example, if the alarm indicates a condition the anaesthetist is already aware of and responding to, then no further action will be triggered by the alarm. The dialogue may continue however, with the anaesthetist seeking to verify the alarm. This stage of the dialogue will involve requests to the monitor to justify its conclusion, and a response from the monitor to the anaesthetist. The dialogue can enter a third stage, when the anaesthetist needs to explore the patient data for further information. For example, the monitor may have suggested several differential diagnoses or have been unable to suggest a diagnosis at all. In this case, the anaesthetist will seek the solution himself, either from clinical observation or by further examination of the patient data with visualization tools provided by the monitor. Equally, the monitor's explanation may be insufficiently detailed, and the anaesthetist may request clarification.
The preceding alarm dialogue will now be examined in more detail. It will be useful to separate out the different levels of abstraction used by an intelligent monitoring device to represent and manipulate knowledge about a patient. We can identify a number of layers, each of which needs to be displayed in some form to clinicians and can therefore engage in some form of dialogue with them. The following layers (figure 2) will be discussed in turn and then their potential for interaction with the user will be demonstrated through the example dialogue:
Layer 1 - Continuous waveform and Numeric Data
Layer 2 - Trends and Range Limits
Layer 3 - Displaying Range Violations
Layer 4 - Diagnostic Interpretations
The heart of any monitoring screen used clinically will remain the display of waveforms and numerical data derived from patient-connected transducers e.g. arterial blood pressure or ECG waveforms. Consequently, dialogues can occur between layer 1 and the user. At this level the `dialogue' is rather limited - there is a one way passage of information from monitor to user.
The second layer of abstraction still stays close to the data, but overlays additional information. By overlaying range limits on a trace, we allow the clinician to identify graphically when a trace departs from these limits, and by compressing the behaviour of a waveform over time we give the clinician additional information about a parameter's behaviour not stored in the rapidly refreshed layer 1 image.
Not only is the content of this layer displayed to the user, but the trend information is also used in the higher processing layers. Much of the inference that can be made by expert systems about specific diseases will relate to the time varying behaviour of patient variables, and the trend will often be the source of this information. Displaying clear trend information will thus become increasingly important as higher layers justify their behaviour by pointing to events in layer 2.
The setting of range limits will become increasingly patient specific as monitors are interfaced with an electronic patient record. Intelligent alarms will use such patient specific information to determine when signals become abnormal in different clinical contexts. Since this patient specific range information will be used in the intelligent monitor's decision making, clinicians will still need some way of visualising these settings. So, rather than remaining static defaults that become devalued as other parts of monitor technology advance, ranges should remain an integral part of the display.
Current monitoring devices usually produce an alarm when a parameter deviates form an expected range. Such alarms form layer three, with the monitor device now moving from a passive display role, to an active assistant role. Range violations depend on the information presented in layer 2 and form the basis for higher level processing in layer 4. We could also include dynamic trend estimation in this layer, where the monitor attempts to interpret patient data to detect the current trend. This should be differentiated from a retrospective evaluation of patient data for past trends in layer 2.
The intelligent interpretation of layers 1 to 3 produces layer 4 alarms. An alarm in this layer might be to signal that a patient has "hypovolaemia" or is in "ventricular fibrillation". The clinician is thus presented with alarms that correspond to entities that are abstract, and usually not directly observable.
The knowledge represented in layer 4 will be mixed to reflect the variation in our understanding of different aspects of the domain. For example, while much work has gone into the development of representations that emphasise pathophysiologic models, it is clear that much of medical knowledge cannot yet be expressed in this manner (Coiera, 1990). Consequently, it would not be hard to imagine a monitor that has access to various forms of medical knowledge: heuristics, pathophysiologic models, probabilistic or neural networks and disease templates.
Knowledge in this layer may be made available to the user for explanatory purposes. The manner in which an explanation is tailored will depend on our user model. For example, succinct explanations would probably be better suited to the needs of an anaesthetist who has to deal with an immediate medical problem which has time as a constraint, but a more detailed explanation of the reasons a diagnosis was suggested may be appropriate in a teaching situation.
There are sufficient problems with the technology in layer four that we cannot yet anticipate when we can generate the type of decision support that higher layers might contain. It is worth however, keeping these in the back of our mind, because of the way the lower layers might interact. We can expect layer 5 to support knowledge intensive task recommendations, based on the diagnostic information generated in layer 4. For example, based upon the interpretation of a patient's clinical state, layer 5 will suggest treatments and interventions. Higher layers can also be envisaged, in which global strategies for patient care are formulated, and each with its own dialogues and impact on interface design.
Having defined the potential sources within an intelligent monitor that may contribute to a dialogue, an example of a dialogue can now be presented (Figure 3). As before, we will look at the exchange between anaesthetist and intelligent monitor after a high level alarm has been produced.
Initially, patient data is processed internally through the first four layers until a high level alarm is generated (1). The external dialogue commences when this alarm is presented to the user (2). Figure 4 offers some simple examples of alternative displays for this part of the dialogue. We may wish to present the alarm as simple text message such as "hypovolaemia" or resort to some form of iconic representation that has meaning to the clinician.We will explore these design issues further in Section 6.
The anaesthetist responds to the alarm message by requesting the system to explain why it believes that the alarm state exists (3). Layer 4 receives this request and processes it. Based upon its user model, it then signals to the lower layers to display those parts of the patient data that it considers will assist this particular user to accept its advice (4). This explanation is then passed back to the user (5). Included in that explanation may well be a stream from layer 4 itself, perhaps as a textual message.
We can see that control of the dialogue is mixed, with the initial control resting in layer 4, as it presented an alarm, and then the user taking control, with a request for further information. It is also interesting to note that the dialogue is relatively short. This would change however, if there was an exchange between the clinician and monitor asking for successively more information on the reasons for an alarm. Equally, if the monitor was capable of suggesting appropriate therapy, we would again envisage more complex dialogues taking place.
Recall that this alarm dialogue belongs to a group of dialogues associated with the general task of detecting abnormal intraoperative events. A second task, the maintenance of an appropriate anaesthetic state would also be active in parallel. It may well be that a dialogue stream from one task area is interrupted by a stream from the other. We could imagine our alarm dialogue being interrupted by a dialogue relating to the lightening of the patient's anaesthetic state. The issue of assigning task and dialogue priority will clearly need to be addressed in this domain. While some prioritisation can be achieved automatically by the monitor system, the anaesthetist should be able to override machine set priorities, and assist with priority assignment.
Part of the user model may contain a description of the informational and ergonomic needs of the user, as well as the user's skill level. A brief assessment of how some of these constraints affect the display of monitor information will now be made, using our layer metaphor. These constraints will be seen to influence our interface options in the examples that follow.
It is difficult to conceive how clinicians, even when presented with potentially more useful methods of displaying patient information, will readily relinquish easy access to seeing layer 1. This is partly a reflection of the inherent conservatism of the profession - they are sceptical about higher levels of decision support, as evidenced by the reluctance to embrace expert systems technology (Shortliffe, 1987). It is also partly a reflection of the ways in which clinicians are educated - they are taught to relate diagnosis and management to the information contained in this layer. Finally, the level of decision support technology available at present will only be able to offer assistance in the interpretation of patient data. Many situations will arise in which the clinician will still have to provide additional interpretation of patient data.
With the development of more sophisticated alarm technology, the temptation has been to crowd these layers onto the monitor screen, along with any additional information from higher layers. Feedback from clinicians suggests that they prefer clear and simple presentation of layer 1 information. A solution to this problem may be to separate monitor screens into two displays - one for layers 1 and another for layer 2 and additional information (layer 3 and higher). This separation also satisfies the differing needs of two different users.- the surgeon and the anaesthetist The first screen could provide a general overview of clinical status that satisfies the operating surgeon as well as the anaesthetist. The second screen could be devoted entirely to the anaesthetist's needs.
Typically, an alarm is signalled by a single audible tone, augmented by a graphical annotation to numeric or waveform data on screen e.g. inverting the numeric associated with an abnormal parameter. There are currently many problems in the way such information in this layer is handled. The strongest evidence for this is the number of times clinicians turn these alarms off. One of the commonest explanations for silencing the audible alarms on a monitor is that most are either false or inappropriate, and studies have indeed confirmed that current generation monitors deliver a high percentage of such `false' alarms. Koski (1990) reported a 90% false alarm rate. The risk with allowing easily silenced alarms on a monitor is that a clinician may miss critical information. Equally, the clinician's senses cannot be bombarded with inappropriate information.
Grice sets out a co-operative principle (Stenton, 1987) that should hold between individuals conducting a dialogue. When one speaks one should endeavour to co-operate with the listener by being accurate, not saying more than is required, sticking to the point, and being clear. False alarms violate several of these maxims relating to the quality and quantity of a discourse by giving the user false information and large quantities of it. It is no wonder that clinicians could lose interest in such a dialogue.
In layer 4 the clinician is presented with alarms that correspond to entities that are abstract, and usually not directly observable. The graphic display of alarms in this layer is thus a challenge. Our discussion of dialogues has been confined to a two way exchange between a user and a computer system, facilitated by an interface. The issue becomes slightly more complicated when considering intelligent monitoring systems. A third party - the expert system - must be considered.
No matter how reasonable or elegant a screen layout may be in the eyes of a designer, if an appropriate cognitive layout is not created in the mind of the user, it will be a constant source of confusion and frustration (Norman, 1986). Thus the need arises to group information according to the major elements of the task, dialogue or user model with which they correspond. The need to hide an expert system, embedding it into existing system software, or bring it out as a distinct element for the user's attention is largely driven by our user model. In some instances, it will not be appropriate to let a user know that an expert system is included in the software he is using. There is however, a strong case to make this element explicit when our user is an anaesthetist using the expert system as an intelligent assistant.
The separation of monitor interface into lower layers and an expert system (layer 4) could be useful for a number of reasons. Firstly, the anaesthetist will use the monitor software for a number of different and contemporaneous tasks - observing and manipulating patient data being one of them. The anaesthetist should be aware that the reliability of the monitor's advisory expert system should not be confused with the patient data presented by the monitor. He should know that the expert system's alarms and recommendations should be treated with a different degree of scepticism from the more fundamental patient information presented by the system. This is because the advisory component of an intelligent monitor does not have full access to clinical context. While it might be connected to a patient record system, and even have access to real time information about drug administration, it will not have ears and eyes. Some diagnostic and therapeutic decisions will thus be made on the basis of information unavailable to the monitor system. Failing to make a clear distinction between advice and data could result in a user distrusting layers 1 to 3 because of perceived inaccuracies in layer 4. Equally, a user might have false confidence in layer 4 because it is associated with the more robust lower layers. Separation will assist in enforcing this distinction.
Secondly, as our discussion of the monitoring layers has demonstrated, part of an expert system's dialogue with a user is devoted to explaining its conclusions with reference to lower layers. It makes sense for these layers to be represented separately. The expert system and user can discuss alarms with reference to the original patient data. This division does not mean that we need to make all the intelligence within the monitor explicit, just that part that the user needs to interact with. For example the components displaying lower level information may hide many intelligent features whose existence we do not necessarily need to highlight to the user. Such features could include the setting of intelligent range defaults, for example.
Now that an alarm dialogue has been presented, and some of the constraints placed upon on the display of that dialogue by the user model have been discussed, some example interfaces that attempt to meet some of these requirements can be presented. These examples should be considered as vehicles for discussion only, and not as serious attempts to design an interface.
Recall that the alarm dialogue presented in section 4 began with layer 4 presenting a high level alarm to the anaesthetist. A large number of such alarms will potentially be derivable from patient data, and because of this it is unlikely that each could be associated with its own icon. It is possible that a subset of common or critical events could be signalled by displaying icons. It seems probable that the most efficient way of displaying most layer 4 information will still have some textual basis. As will be shown below however, this does not mean that the extensive use of graphics from the lower layers cannot be used to reinforce layer 4.
As we have seen, once an alarm like "hypovolaemia" is signalled, the clinician may then ask for an explanation. Part of the explanation may come directly from layer 4. It is unlikely that a large amount of text would be appropriate for the explanation, although some form of natural language based explanation might be useful as a `detailed explanation' option. One potential method for the rapid and effective display an alarm explanation is to use a causal sentence. This is actually a shorthand notation that is frequently used in one form or another by clinicians, and can often be found in text-books. For example, a sentence explaining hypovolaemia might be:
The sentence is intended to convey that a decrease in CVP leading to a decrease in BP was the trigger for a hypovolaemia alarm. Although the elements of the sentence are mainly text based, the familiarity of clinicians with such representations means that they could almost be considered iconic - they act as simple graphical representations of complex objects. While this is a relatively short explanation, one can envisage quite extended chains of reasoning producing an alarm. In such cases, the level of detail presented to the clinician will depend both on the user's requests as well as knowledge stored in the user model. Presenting explanations at increasing levels of abstraction has been a theme in much medical AI research for some time (e.g. Patil, 1981).
As we saw in the alarm dialogue, part of the explanation layer 4 might offer a clinician could come from lower layers. For example layer 4 might augment its textual explanation by highlighting in some way, parts of the data displayed that influenced its decision. In other words, we wish the user to group a subset of the displayed information and treat it as part of an explanation.There are many ways of inducing a user to group disparate information elements from a screen display e.g. spatial and temporal grouping (Norman, 1986). Another grouping mechanism is to use similar colours to indicate related elements. In fact, colour can be used throughout our alarm dialogue sequence, beginning with the display of abnormal patient data. The key issue in the example that follows is that whatever techniques we might choose to group elements that appear in our interface, that the grouping be based on an understanding of our user model and the current dialogue.
At present most patient monitors use colour to differentiate between different signals. There is no clear standard for making these associations, and it seems that different clinicians use different colours for the same signals. In addition, the position of each trace is also often configurable by clinicians, and they can use this information to assist in rapid trace identification. So it is unlikely that colour is being used optimally.
We could thus use colour to highlight a trace when it displays a range violation. Perhaps the trace itself would change from its normal colour, or its background would change colour. A three colour hierachy corresponding to alarm status could be used. Normal traces are green, turn yellow when they cause a yellow alarm, and red when they trigger a red alarm. There are some obvious advantages to this simple suggestion as well as some implications for layer 4.
Firstly colour coded abnormal traces should generate a strong visual alarm. In this case, staring at a trace for a while may be associated with a gradual reduction in vigilance on the part of the clinician. A change in colour coding will signal clearly that a new event has occurred. When two or more range violation alarms are activated, colour encoding comes into its own. Firstly, most multiple channel monitors signal the same single audible alarm whether one or many parameters are abnormal. Using colour alarms assists the clinician to rapidly determine which parameters are abnormal. Secondly colour can encode alarm priority. With concurrent red and yellow alarms, the clinician rapidly can decide which trace is the red one and direct attention there.
There are also implications for Layer 4, since many of the checks that an intelligent alarm system will make can be made visible to the clinician. In particular, colour highlighting trend information will allow a clinician to formulate causal hypotheses. If one parameter becomes abnormal before another, the time order of events becomes highlighted graphically on the trend display. The capacity to make causal inferences directly from the monitor display has the potential to be very useful clinically.
In a similar vein, here are numerous possible extensions to the use of colour. For example, repetitive signal patterns e.g. cardiovascular measures, can usually be directly mapped to a common part of the cardiac cycle. If we wished, two cardiovascular signals could have their temporal linkage encoded with a shared alternating two colour background. The period over each heart beat would be associated with one of two alternating shades, producing an alternating background colour stripe over time. When the regularity is broken e.g. the linked signals are no longer synchronous, an alarm colour could be used as background (Figure 5). This could have great clinical utility. For example, when pulse rate and the ECG don't synchronise then electro-mechanical dissociation may have occurred. This display could be a rapid way of signalling such "linkage" abnormalities, and offer a rapid way of verifying layer 4 alarms derived from it. The decision to make such a grouping is driven by an assessment of the user's current needs. If visualising signal linkage is critical to the performance of the current task, then highlighting it in this way may be beneficial. If it is a minor concern, then presenting this grouping with such a strong visual cue would detract from the more important dialogues that might be occurring.
Layer 4 can use colour to select out parts of the layer 1 to 3 display that it believes will be useful in its explanation of an alarm for the clinician, based on its user model. Continuing with the hypovolaemia example, we could justify both the diagnosis and its causal sentence by highlighting those parts of the trend data that lead to the conclusion, using an appropriate colour scheme (Figure 6).
If competing hypotheses are presented to the clinician for further investigation (probably a common occurrence until monitors have access to patient records and treatment data), then clicking on alternative hypotheses would cause the highlighting of parts of the data used in each formulation to appear. It may be clear to the clinician that one set of highlights associated with one hypothesis corresponds to significant abnormalities on the patient traces, while the second is a poorer match. Such techniques will be invaluable especially if, as is likely, much of the reasoning performed in generating layer 4 alarms is based on qualitative techniques (Coiera, 1990).
Layer four can also help to assign channel priority. Recall that we could distinguish the priority of range violations by highlighting traces with different grades of alarm colour. Using parameter rangesfrom level two, such priorities would be based only upon the degree of deviation from the normal range. Perhaps abnormal and very abnormal levels are defined for each parameter. Level four can decide which abnormal signal is important based upon information about causal relations between signal changes, and clinical importance. So we now have a way of graphically relating value judgments about priority to the clinicians. The ease with which information can pass between display layers should indicate the value of potential graphical representations.
A number of alternative methods of presenting information with a patient monitoring system have been suggested in the literature. Rather than offering an exhaustive review, a few points will be made from an illustrative case to demonstrate the types of problem that can be encountered.
The Circle Diagram (Siegel, 1983) constructs a multi-sided polygon in a multi-variable space. Each axis of the circle corresponds to a measured patient parameters and a point is plotted on the axis for that parameter's current value. When the current value points for all parameters are joined up they form a polygonal shape. When a parameter becomes abnormal, then its corresponding point moves, deforming the `normal' polygonal shape (Figure 7). The intuition behind this display is that clinicians will learn to recognise distinctive polygon shapes that correspond to particular disease entities
Such a strategy abstracts away the lower display layers in an attempt to present a concise summary of events to the clinician. However, when offered as a strategy for displaying information to clinicians, it has a number of shortcomings. Critically, it ignores the notion that an interface should map the user's mental models and tasks (other offerings in the literature are similarly limited e.g. (Fukuwi, (1987), Sekia, (1984)).
For example, the representation is not familiar to clinicians, and its use would require an amount of learning. A clinician unfamiliar with the representation cannot walk up to a display and say immediately, for example, that the pattern "looks like vasoconstriction". The display would need to be interpreted, probably with a greater degree of difficulty than direct inspection of a patient's trended data. It is unlikely that medical schools will conduct courses on the recognition of common patterns with such displays, and it is unlikely that clinicians will amass this knowledge experientially without much effort.
Clinicians could conceivably however, use the patterns for a quite different task - not for diagnosis, but for the concise summarisation of progress once a diagnosis has been made. For example, they could be used to watch the recovery of a patient following administration of treatment. It is not clear however, that such methods will be necessarily superior to well presented trend information. Finally, these representations ignore the value of dialogue. Information is presented in one way only, from system to user. There is no inherent mechanism for query or explanation associated with these methods.
A number of aspects of the anaesthetic user model have been noted through this paper, both while discussing the constraints the user and dialogue place upon the various monitor layers and in relation to alternative strategies in the literature. These points can now be usefully summarised into an initial set of general interface requirements for intelligent monitors.
Clinicians may take a long time to accept the technology offered by intelligent decision support systems (their track record supports this), and will need to reassure themselves that computer generated recommendations are valid. Ready access to the clinical information that produced the decisions seems critical. Further, coupling a new decision support technology with a novel (and perhaps innovative) display technology will almost certainly alienate clinicians by decoupling them from primary clinical data. They will be left without a point of reference to their past clinical experience.
The advice offered by an embedded expert system needs to be differentiated from the more certain patient data offered by the monitor. In particular, we wish the anaesthetist to learn to question high level alarms produced by the monitor. Separating the two prevents alarms being associated with the more certain data and gaining more credibility than it deserves. Equally it prevents the anaesthetist from associating the errors that an intelligent alarm system will make with the lower layers in the system. The tendency here would be for a user to rubbish a whole system because he could not distinguish the differing roles and computational basis of the intelligent alarm and data displays.
A graphical display will not be useful if a clinician who is unfamiliar with the monitor cannot walk up to it and make some sort of valid interpretation. Equally, expecting clinicians to learn diagnostic patterns in novel graphic displays will probably not be successful. The display of abstract events should be as intuitive as possible, and not impose the need for added interpretation on the clinician. For intermediate representations of changes in patient state to be successful they should perform better than well presented trend data.
The explanatory power of patient data should be used when justifying high level alarms whenever possible. Each monitor layer implicitly contains display information used by the next layer and when explaining a higher layer with a lower, the relation can be made explicit. Information should move easily between layers
This paper has focused on the development of a user and dialogue models for the interaction between anaesthetist and an intelligent monitor system. Rather than making any explicit claims about the value of particular interface designs, the examples presented here demonstrate how one might build such models. Thus the emphasis has been on the process of development of an interface, rather than the final product. The example dialogues presented have been short, but one would expect that as significant capabilities were added to monitoring systems, that they would become increasingly complex. For example, the process of assessing, and refining a therapy plan between anaesthetist and monitor could potentially be quite long.
To make a full assessment of the benefits of user and dialogue modelling, there now needs to be a formal assessment of the characteristics anaesthetists bring with them to the interaction, as well as an examination of the full range of dialogues that can occur in an operating room between anaesthetist and monitor. Clearly the whole issue of interface design is a complex one, and this design needs to be conducted in a systematic way. Further, it must be conducted in close liaison with the clinical environment. A focus on user tasks will force us to think first of the true domain requirements rather than leaping to technologically motivated solutions.
It is probable that the development of practical user interfaces for intelligent monitors will be limited more by our lack of understanding clinical cognitive processes of users, than by limitations in interface technology. Undoubtedly new technologies will improve the `naturalness' of dialogues between user and computer, but our commitment should be to understanding the user and their dialogues first, and then use this knowledge to assist in selecting appropriate interface technologies.