MET Research Working Paper MRWP-01/2004
Designing Interactions for Mobile Clinical Decision Support Systems: The MET System Perspective
Wojtek Michalowski
University of Ottawa, Ottawa, Canada
Szymon Wilk
Poznan University of Technology, Poznan, Poland
Marta Kersten
Queens University, Kingston, Canada
© 2004 MET Research Group Unpublished intellectual property. Can be quoted only with the authors' permission.
Designing Interactions for Mobile Clinical Decision Support Systems: The MET System Perspective Wojtek Michalowski, Szymon Wilk, and Marta Kersten
Abstract This paper describes the design of interactions for mobile clinical decision support systems, and illustrates a proposed approach with the MET (Mobile Emergency Triage) system used for triaging patients in the Emergency Room of a hospital. The design is based on an interaction framework that maps the user’s mental representations of the task at hand into input and output components of interactions. It is proposed to use a scenario-based design to encapsulate the user’s representations, and an Object-Action-Interface model combined with the Eight Golden Rules of Interface Design to design the input and the output components. These theoretical solutions are implemented in the MET system and discussed in the paper for the clinical application of triaging abdominal pain patients in the Emergency Room. Keywords: interaction design, Object-Action-Interface model, scenario-based design, handhelds, clinical decision support systems, Emergency Room triage
1. Introduction The process of clinical decision making involves gathering and evaluating information about a patient, and applying medical knowledge to decide as to the definitive
1
management (diagnosis, prognosis and therapeutic options) of the patient’s medical condition [1]. Within a hospital Emergency Room (ER), medical personnel make triage decisions in order to assess whether a patient requires urgent attention from a specialist, or whether some other course of action needs to be taken. Based upon information from the patient’s complaint, history, physical exam, and the results of laboratory tests, physicians and allied health professionals make decisions about the severity of the patient’s presenting condition, and the management process that follows. Generally, the triage process for non-trauma cases in the ER involves two assessment phases, which respectively answer these questions: how quickly does the patient need to receive medical attention, and what type of clinical management is necessary. The first phase, or so-called prioritization, is done by a triage nurse, who gathers basic information on the patient’s presenting complaint, and makes an initial assessment of the severity of the case. This results in assigning the patient to an appropriate priority category. Demographic information is gathered at the same time, and then priority scheduling is established, so that the more severe cases are seen first. The second phase, medical assessment and disposition, involves the ER physician, who upon collecting more information on the patient’s history, conducting a physical exam and reviewing tests, makes the initial decision as to whether a specialist consult might be required, further inhospital observation is needed, or whether the patient can be discharged to the care of the family physician. Regular patient management follows the assessment process. It is the medical assessment and disposition phase that we are concerned with in this paper, and for simplicity we will refer to it as the “triage”.
2
We would like to emphasize that triage is not synonymous with diagnosis. The latter answers the question, “what is the cause of the patient’s problem?” while the former addresses the means of managing the problem in the short term. Thus, on one hand, triage seems to be easier, as outcomes are limited to only a few possibilities (as described above), but on the other hand, it is more difficult, because much less data are available at this point of the patient management process, and a decision has to be made under strict time constraints. The triage support is very important, as facilitating it has an impact on the length of the patient’s stay in the ER, the number of investigations, and laboratory tests. The MET (Mobile Emergency Triage) [2] system is a clinical decision support system (clinical DSS) aimed at facilitating the rapid ER triage of children with varying acute conditions. MET is designed as a multiplatform client-server system, with clients that run on a desktop computer and on mobile devices (e.g., a handheld computer or a cell phone). In this paper we will describe the handheld-based client of the system, and will refer to it as MET. The fact that MET is designated for use in an ER environment poses specific requirements in designing the interaction (communication) between the system and its users. It must be quick and easy to follow, allowing the attending physician to continue his/her patient management without unnecessary external interference, and with no increase in the cognitive burden associated with the use of the system. These were the guiding principles behind our design of the interaction in the MET system. It is important to stress here that designing the interaction, as considered in this paper, means more than just designing an interface. It involves the interplay between what a physician can do with
3
MET, and what the system does in return. Such an approach provides mapping between the interface models and the mental representations of the physician’s tasks. Most of the clinical DSS discussed in the literature are designed to support clinical tasks away from the patient’s bedside. The MET system, on the contrary, is designed to support triage – a task that relies on a limited amount of information about the patient’s condition, and is conducted under time pressure directly at the bedside (at the point of care). Thus, a physician using the triage support system has no time to consult a desktop computer located in some other room (most examination rooms in the ER do not have enough space to accommodate a desktop system), and therefore she/he is looking for a “handy” support tool that does not interfere with clinical workflow, and is available at the point of care. Provision of support at the point of care became possible only recently due to the advances in mobile computing technologies, and it is not fully explored in the field of clinical DSS. A clinical DSS available at the point of care needs to fit well with the workflow (ER triage in case of the MET system), needs to maintain a format of interactions that is known and acceptable to health-care professionals and is easy to follow in ER conditions. These are the guiding principles that we used in designing MET system interactions. The paper is organized as follows. In Section 2 we give a brief overview of approaches to designing human-computer interactions in clinical DSS. In Section 3 we discuss the development and design of the MET interactions. Finally, we conclude with a discussion.
4
2. Interactions in Clinical DSS A clinical DSS is “any program designed to help health-care professionals make clinical decisions” [3]. This very general definition covers several categories of information systems, including: •
Systems for patients’ information management and retrieval,
•
Systems for monitoring and alerting health-care staff about a patient’s condition that requires attention,
•
Systems for providing patient-specific assessments or advice based on clinical data.
Systems from these classes are meant to be used in different environments, from sites of accidents to hospital registration offices, and by diversified groups of users, from secretarial staff to physicians. This impacts the way in which the interactions (matching clinical tasks to system functions, organizing communication between users and the system, and planning the interface [4]) should be designed, and makes such design a difficult and challenging task. However, as we are arguing below, some basic principles are common to all these categories of systems. The first two categories of clinical DSS have been used in practice for at least three decades [5], mainly in the form of electronic medical record systems [6], and alerting and monitoring systems [7] integrated with medical devices: e.g., vital signs monitors, ventilators or pumps. Systems from the first category, patients’ information management systems, are normally used away from the point of care, and operated mostly by clinical support staff ( nurse 5
practitioners, medical assistants) [8]. This distant-from-the-point-of-care usage of these systems makes the design of interactions a challenging task, as it is relatively easy to introduce disruptions to the clinical workflow, which results in the system’s rejection by health-care professionals [5], [9] (there are reports about systems that had to be withdrawn from clinical practice because of the lack of acceptance [5]). Therefore, the main requirement for interactions in these systems is their fit to the clinical workflow [5][6]. This fit can be successfully accomplished by designing the interactions according to a user-centered design [10], and involving end-users in the development process by asking them to prepare scenarios of possible system uses, and to evaluate proposals prepared by the developers [10]. Moreover, it is advocated that the interactions in these systems apply the principles of task-centered design [11]-[12] so that the user interface adheres to the following requirements [6]: •
information should be presented in a way that helps the end users to focus on the key data,
•
terms and notions should be familiar to end users and should relate to their work,
•
mistakes should be easily corrected,
•
routine tasks should be performed in a straightforward manner.
Systems from the second category, especially the ones integrated into medical devices, are used in a very different context. Usually they are deployed directly at the point of care [7], [13], where medical personnel work under stress undertaking time-critical tasks. Locating these systems at the point of care naturally imposes a fit to the workflow. However, the interactions in these systems are still designed following the principles of
6
user-oriented and task-oriented designs [7] – because of a nature of these systems it is very important that the interactions are designed is a way that a user is capable to focus entirely on the task at hand. These design guidelines are also governed by legal regulations [14], and they are often augmented by very specific instructions on how to create user interfaces to minimize the possibility of an error. These instructions emphasize the following features of an easy-to-use, and error-proof interface of the medical devices [15]: •
reduced screen density,
•
navigation cues and options,
•
visual balance,
•
a limited number of colors,
•
simplified typography and language,
•
no inconsistencies.
The last category of clinical DSS appears to be underrepresented in clinical settings – many of these systems have been developed as scientific projects, intended mainly to be proof of concept, and were not tested in practice [3], [16]. Only a few were introduced into the daily clinical routine [17]-[18], with attention paid to the design of the interactions. These systems, similar to information management systems, were used away from the point of care, so fitting the workflow was the critical requirement [3], [5]. Another issue that arises in the case of systems that give patient-specific advice is the degree of their automation – physicians will not accept a system that will make clinical decisions automatically [5]. Therefore, when designing interactions, the system has to be 7
assigned the role of a helper/assistant, not an oracle [19]. Moreover, these systems should save their users from performing mundane tasks like entering information that is available elsewhere in electronic form. Therefore, integration with patients’ information management systems is another key factor in the successful deployment of these clinical DSS in clinical settings [3], [19]. The development of mobile computing devices and wireless communications [20] made it possible to move a clinical DSS directly to the point of care. This offers the opportunity for easier integration with the clinical workflow [21], as clinicians can now use the clinical DSS when and where it is necessary, not when they are at a workstation. However, this new opportunity makes the design of interactions more difficult because they should fulfill the requirements similar to those expected from monitoring and alerting devices. MET offers patient-specific advice directly at the point of care where medical personnel are under pressure to make quick and accurate triage decisions. Therefore, it must not only fit the workflow (or better yet, become part of the workflow), but it also has to rely on the interactions that allow clinicians to operate it easily, quickly, with no cognitive burden, and with minimized opportunity for misinterpretation. The design of MET discussed in the next section adheres to these requirements.
3. Interactions in the MET system The general framework of human-computer interaction [4] consists of four major components that form an interactive system: the system, the user, the input, and the
8
output (the latter two form the interface). Each component has its own representation: e.g., for the user, it is the mental description of the task he/she wants to accomplish. The cycle of interaction includes the following actions that map the representations associated with each of the components (Fig. 1): •
Articulation – the action of mapping the user’s mental representation to the input requirements,
•
Performance – the action of translating the input representation into a computeracceptable representation,
•
Presentation – the action of translating the system’s results into a representation acceptable by the output component,
•
Observation – the action of mapping the output representation into the user’s mental description.
From the system’s design perspective, it is very important to design the input and output representations in such a way that there is an unequivocal mapping between them and the user’s mental description, as only then will the user be able to easily articulate the task, and will have no problems interpreting the output. The system’s representation is not as crucial because the translations that take part (performance and presentation) do not involve the user, and their difficulty is confined to computational complexity only.
9
Presentation
Output
Observation
System
User
Input Performance
Articulation Interface
Fig. 1. The interaction framework
For successful interaction with the system, the interface should be designed in such a way that the user can articulate his/her mental concepts (articulation) so that they are accepted by the system (the input), and the results of the system’s operation are presented (the output) in such a way that the user can easily map them (observation) into his/her mental concepts. The main issue of interaction design is to properly capture the user’s articulation, and to support the user’s observation in the interaction cycle. Shneiderman [22] presents the following basic taxonomy of requirements for designing the interface components (the input and the output) of the interaction: (1) High-level theories, (2) middle-level principles, and (3) specific and practical guidelines. He states that “the theories and models offer a framework or language to discuss issues that are application independent, whereas the middle-level principles are useful in creating and comparing design alternatives. The practical guidelines provide helpful reminders of rules uncovered by designers.” Following this taxonomy, we used the scenario-based design model [23] and the ObjectAction-Interface model [22] as the general theory behind the MET interactions; domain-
10
specific design [24] as a middle-level principle; and well-established guidelines, like the Eight Golden Rules of Interface Design [22], and specific interface solutions for mobile devices [25] as the practical guidelines. The Object-Action-Interface (OAI) model offers a way of designing the input and output representations using knowledge about the user’s mental description of the task. It is based on the principle that for each user task we can distinguish a set of objects and a set of actions that manipulate these objects. According to this model, each object composing the user task needs to have its equivalent as an interface object, and each action on the task objects needs to have the equivalent of an interface action. Such one-to-one mapping should guarantee that all user tasks can be easily accomplished with the help of the interface as each object and action constituting a mental task will have its interface equivalent. Applying the OAI model to the interaction framework presented in Fig. 1 implies that articulation represents a one-to-one mapping between task objects and actions and input objects and actions, and observation represents a one-to-one mapping between output objects and actions and the objects and actions that comprise the user’s mental task description. The scenario-based design relies on descriptions (scenarios) of how users might accomplish their tasks with the help of the system, and thus it is very useful for exploring the user’s mental description of tasks, so objects and actions for the OAI model can be correctly identified. Scenarios, developed with the significant involvement of the users, are represented as primary design requirements. They are created before the actual system is developed, and they focus on the expected functionality of the system. Scenarios can 11
also be applied to design the system’s functionality, and to evaluate and review the specific design solutions in order to check if all the usability goals have been satisfied. As the scenario-based design is concerned with how users execute tasks in their totality, it can be seen as encompassing user-centered [11] and task-centered design [12] used in the development of interactions for clinical DSS. The former design exploits cognitive commonalities among the class of potential users of the system, and identifies specific features of the system that need to be in place to meet user requirements. The latter involves supporting only representative tasks that users perform, thus resulting in a system that is easy and intuitive to use. The interactions between the MET system and the user called for solutions that will not deter from the clinical workflow: i.e., using a handheld, entering information and running the triage function needn’t be an obstacle to performing regular examinations and assessment. To design these interactions, we began by observing physicians performing the triage task, including recording information on paper charts and making triage decisions. Normally, upon patient’s admittance to the ER the attending physician takes a paper chart with information retrieved from a hospital information system, evaluates a patient recording required data, makes a triage decision and proceeds with management. Linking such a workflow with tasks supported by the system resulted in the following schematic scenario. First, MET automatically retrieves patients’ electronic record from a hospital information system for those patients that are to be seen by the ER physician. Then, the ER physician enters new data directly into a handheld and is able to invoke the triage function as he/she wishes. Data collected during triage are transferred back to a hospital information system so they become available for use at later stages of the patient
12
management process. An example of one of many scenarios created to describe the use of MET to support the triage is presented in Fig. 2. Dr. F. examines a 6-year boy, brought to the ER by his parents and complaining of abdominal pain. He begins by recording the patient’s history – asks about the type of pain, its duration and location. He then proceeds to conduct the physical examination and checks for abdominal tenderness. Unfortunately, the child is very anxious and does not allow the doctor to touch him – he cries and fidgets. Finally, Dr. F. is able to examine the child’s abdomen and notices that it is tender in the lower section. He records the information, but since the examination was obstructed by the child’s behavior, he writes an additional explanatory note. At this point, he is interested in a possible triage and runs the triage function of the system. The suggested disposition is observation; however, the strength of this recommendation is marked as medium. This is consistent with what Dr. F. thinks, so he decides to order blood work before deciding about future management. Once the results are available, Dr. F. enters the new data and invokes the triage function again. This time, the disposition of observation is strongly recommended, supporting Dr. F.’s management decision to keep the child for further in-hospital investigation.
Fig. 2. Sample scenario of MET usage
13
Analysis of scenarios led to the selection of the OAI model, partially illustrated on Fig. 3 (for the sake of clarity, not all connections between actions are given). According to this model, the patient is characterized by clinical attributes that in turn are described by their values and optional notes. Triage of a patient involves two types of activities – recording the values of clinical attributes grouped into three categories: signs, symptoms and tests, and formulating a triage decision upon acquiring a sufficient amount of information. Nonetheless, it should be possible to establish triage outcomes irrespective of the amount of available information, as it depends on the physician – it can vary from a small amount for an experienced staff physician, to a complete set of data for an inexperienced medical resident. The values of attributes are collected through a face-to-face interview with the patient (symptoms), performing a physical examination (signs) and ordering laboratory tests (tests). These can be supplemented with notes containing additional information. There is no fixed and approved sequence of activities in which the values are gathered.
Triage
Patient Record symptoms
Record signs
Record tests
Make a triage decision
Clinical attribute Record an attribute
Attribute note
Attribute value Record a value
Objects
Write a note
Actions
Fig. 3. The OAI model for the triage task
14
Following the principles of the OAI model, we established a set of interface objects and actions presented in Fig. 4. (Some connections between actions have been removed to make the diagram readable.) The hierarchy of interface objects is exactly the same as for task objects, and it is made more specific by specializing the action of recording the value into: •
recording the value from a finite set of possible choices (e.g., yes or no),
•
recording the value from an infinite set of possibilities (e.g., a numeric value).
The former action is specialized even further – into recording a precisely defined (precise) value, and an imprecisely defined (imprecise) one.
Emergency triage
Patient
Record symptoms
Attribute
Record an attribute
Record signs
Record tests
Call a triage function
Make a note Attribute note
Attribute value
Record a value
Record a value from a finite set
Record a precise value
Objects
Record a value from an infinite set
Record an imprecise value
Actions
Fig. 4. The OAI model for the interface
15
The OAI model was implemented in MET following the principles of domain-specific design that considers cognitive tasks specific for the domain while designing the interactions. The users of the MET system, ER physicians and residents, are usually more familiar with filling out paper charts, evaluating patients, and interpreting the results of the tests than with operating a computer (especially a handheld with handwriting recognition). After consulting with the users, we used domain-specific metaphors (e.g., pictograms, symbols, codes and shortcuts) to represent the interface objects and actions. As interface actions directly correspond to task actions, there is no pre-defined sequence of activities – attributes can be evaluated in any order and a user may invoke a triage function at any stage of the process. To minimize the potential obstruction of the triage task, the system offers easy navigation between main functions. They are immediately and easily accessible from all locations – it takes only one user action to invoke them – consistently with general guidelines for interface design stating that the most frequent actions should be exposed to the user [22], and with specific guidelines for developing applications for medical devices [15] and handheld computers [25]. On the higher level of interaction, the user is offered access to the four main triage actions – reviewing the patient’s history, recording the symptoms and signs, evaluating the tests, and calling for the triage function. These actions are labelled with the names and codes used on paper charts: history (Hx), physical exam (PE), tests (Ix) and triage (TR) accordingly (Fig. 5). On the lower level of interaction, for recording attributes, the user has direct access to entering values and making the notes (Fig. 6).
16
Fig. 5. Navigation between main triage actions
Fig. 6. Navigation between recording attributes
The action of recording a specialized value is implemented in the MET system using the menu selection interaction style for the finite set actions, and form fillin style for the infinite set actions [22]. The menu selection style requires the possible choices to be understandable and distinct. In practice, the precise distinction may be difficult to achieve because of the observer-dependent bias, and it may lead to recording imprecise values,
17
e.g., the same location of pain may be described by one physician as the lower abdomen, and by another as the right lower quadrant. To address this problem, we further specialized the action of recording the value from the finite set into recording a precise or imprecise value. Precise values can be clearly distinguished and identified, so it is sufficient to record them by using a simple menu selection list without any additional explanation (Fig. 7).
Fig. 7. Recording a precise value
An imprecise value does not allow for accurate identification, and thus recording it requires additional support. For the abdominal pain triage task, imprecise values are associated with the attributes indicating the location of the clinical condition on the abdomen. Therefore, we decided to supplement the lists of values with pictograms of appropriate body parts to introduce consistency, and to diminish the potential for ambiguous interpretation. Moreover, to ease interactions, the menu selection technique was augmented with direct manipulation [22], so that a value can be selected directly from the list, or by tapping a corresponding section of a pictogram (Fig. 8). 18
Fig. 8. Recording an imprecise value
When implementing the form fillin style for recording the value from an infinite set, we decided on a solution that does not rely on handwriting recognition for data entry. As all the values coming from an infinite set are numerical (for example, results of laboratory tests), we implemented the recording action using a numeric keypad that mimics a phone or a calculator pad (Fig. 9). However, adhering to one of the Eight Golden Rules of Interface Design, stating that advanced users should be able to use shortcuts, it still is possible to enter such values using handwriting recognition.
19
Fig. 9. Recording a value from an infinite set
The action of recording the note associated with a given attribute’s value is logically similar to recording a value from an infinite set. Thus, when implementing this action we followed the form fillin style, and to save the user from extensive use of the handwriting recognition system or the virtual keyboard, we created a glossary of commonly used terms that can be used to compose abbreviated note statements (Fig. 10). The glossary was developed from the analysis of hundreds of paper charts, extracting frequently used terms and expressions from notes made by physicians in the charts. However, it can be easily modified by a user by adding new entries or deleting less frequently used ones.
20
Fig. 10. Recording a note
The triage recommendation provided by the system should be considered as a reminder for possible outcomes, rather than an oracle [19]. It should also reflect the nature of nondeterministic clinical reasoning. Considering that, and providing the physician with the ability to have full control over the system, the triage function after consulting the appropriate rule-based decision model returns all possible disposition decisions together with associated strength factors [26] (Fig. 11). The recommendation that acquired the highest strength is indicated as the suggested one. Presenting multiple recommendations with their strengths further stresses the precept that it is the MET user that makes the triage decision; the system just furnishes additional information to be evaluated.
21
Fig. 11. Evoking a triage function
4. Discussion Medical professionals often view a clinical DSS as requiring too much learning time, and not meeting their needs. Thus, it was important that the interaction framework implemented in the MET system supports the cognitive tasks of ER physicians and residents, allowing the interaction to be timely, intuitive and natural. The greater the cognitive burden associated with usage of the system, the less likely it is that it will be accepted [27]-[28]. Previous research demonstrated that for a clinical DSS to be used in practice, it has to fit the workflow process [3], [5], [9], [29]. It is especially true for any system supporting ER triage. Therefore, the MET system allows the interaction to take place while the ER physician performs the patient interview and physical exam, and provides for a seamless transition between the data gathering and data entering actions. The use of easy-to-carry handheld computers that can be operated at the point of care, when and where MET is needed, avoids interruptions to the clinical workflow, and thus satisfies one of the most important requirements for a clinical DSS to be successfully 22
introduced into regular practice [3], [5]. Physicians using MET do not have to leave the patient in order to obtain triage recommendation, and the use of the system can easily become part of their routine, making decision support an integral part of their workflow [3]. Other research suggests that it is the way to deploy decision support in hospital setting – several attempts at introducing clinical support systems that imposed changes to the workflow [5], [9], [30] failed, because the end users found them too cumbersome to use. The MET system is designed for the ER environment where any obstruction of the task at hand makes the system unacceptable. The ER physicians will be consulting the system while working under pressure, when there is no time to manoeuvre around a desktop computer, and the need to consult the system could be perceived as a hindrance. The system does not follow a sequential path to derive at recommendation, but allows users to enter information as they deem necessary, and it is capable of providing a triage recommendation at any stage in the process. Such approach is in line with a manner a triage task is conducted. Depending on a severity of patient’s health state and individual practices of the attending physicians, a triage decision can be reached using variable amount of information making it almost impossible to identify a core set of data that is required. These conditions further reinforced our approach to designing the interactions that assumed that the task of the ER personnel is to provide quality health care to patients, not to operate a computer. To this end, we used feedback from the intended user group, including medical students, residents, ER physicians and paediatric surgeons, in developing possible scenarios of MET usage, and developing the OAI model of interactions. This end-user involvement in designing the system, combined with
23
adherence to well-established principles of human-computer interactions, allowed us to create an interaction framework that is intuitive, easy to follow, and aligned with the tasks of triaging a patient. Moreover, the proposed framework supports the collection of the patient’s data in a structured manner, and contributes to organizing and structuring the decision making process. Several clinical studies [31]-[32] demonstrated that structured data collection improves diagnostic performance. This factor alone should not be overlooked when designing the interaction for a clinical DSS. Finally, we would like to note that although this interaction framework was used to build the system for a handheld computing platform,, it can be easily modified to fit any target platform. Reliance on Shneiderman’s taxonomy of requirements [22] while creating MET’s interaction framework implies that only specific guidelines need to be modified to fit a particular platform. For example, the easy navigation specified on the high level can be implemented on a handheld computer with graphical buttons invoking necessary functions, and on a mobile phone with the keys on the keypad assigned to these functions. The MET system underwent a successful clinical trial in the ER of a children’s hospital. The trial lasted for 7 months and involved triaging patients with abdominal pain. During that period 2255 patients with abdominal pain visited the ER, and 574 participated in the trial (the others did not satisfy eligibility criteria, or were not triaged using the MET system). Patients and their caregivers were very positive about the system, as only a few refused to participate in the trial, and many emphasized that using MET did not involve any additional examinations or tests, and did not lengthen the stay in the ER. The MET system was used by over 50 members of the ER staff (physicians and residents). This 24
group had diverse prior experience with handheld computers, ranging from complete novice to advanced users experienced with medical applications. All users participated in short orientation sessions and were able to operate the MET system without any difficulties, and were satisfied with the design of interactions and with the system’s fit to the clinical workflow. Such positive practical experience further strengthens our approach to designing desirable interaction framework for clinical DSS that is used at the point of care.
Acknowledgment The authors would like to thank Dr. Ken Farion and Dr. Steven Rubin from the Children’s Hospital of Eastern Ontario for advice regarding the triage process. Dr. Farion was also responsible for managing the clinical trial of the MET system in the hospital’s ER. Robert Payne and Bernard Plouffe helped us with designing selected components of the MET system interactions. The authors would like to thank the reviewers for their helpful comments and suggestions, and Anne Burgess for editorial assistance.
25
References [1]
H.R. Warner, A.F. Toronto, L.G. Veasey, R. Stephenson, “A mathematical approach to medical diagnosis: application to congenital heart disease,” JAMA, vol. 177, no. 3, pp. 177-183, 1961.
[2]
W. Michalowski, S. Rubin, R. Slowinski, Sz. Wilk, “Mobile clinical support system for pediatric emergencies,” Journal of Decision Support Systems, vol. 36, no. 2, pp. 161-176, 2003.
[3]
M.A. Musen, Y. Shahar, E.H. Shortliffe, “Clinical decision support systems,” in Medical Informatics: Computer Applications in Health Care and Biomedicine, E.H. Shortliffe, L.E. Perreault, G. Wiederhold, L.M. Fagan, Eds. Springer-Verlag, 2000, 600-639.
[4]
A. Dix, J. Finlay, G. Abowd, R. Beale, Human-Computer Interaction, 2nd ed. New York, Prentice Hall, 1998.
[5]
J.G. Anderson, “Clearing the Way for Physicians’ Use of Clinical Information Systems,” Communications of the ACM, vol. 40, no. 8, pp. 83-90, 1997.
[6]
D.F. Sitting, G.J. Kuperman, J. Fiskio, “Evaluating Physician Satisfaction Regarding User Interactions with an Electronic Medical Record System,” in Proceedings of AMIA’99 Annual Symposium. 1999, 400-404.
[7]
D.S. Brown, S. Motte, “Device Design Methodology for Trauma Applications,” in Proceedings of the SIGCHI conference on Human factors in computing systems. Los Angeles, California, 1998, 590-594.
26
[8]
N. Folz-Murphy, M. Partin, L. Williams, C.M. Harris, M.S. Lauer, “Physician Use of an Ambulatory Medical Record System: Matching Form and Function, ” in Proceedings of AMIA’98 Annual Symposium. 1998, 260-264.
[9]
J. Wyatt, “The evaluation of clinical decision aids: a discussion of methodology used in the ACORN project,” Lecture Notes in Medical Informatics, vol. 33, pp 1524, 1987.
[10] A.L. Rector, B. Horan, M. Fitter, S. Kay, PD. Newton, W.A. Nowlan, D. Robinson, A. Wilson, “User Centered Development of a General Practice Medical Workstation: The PEN&PAD Experience,” in Proceedings of the SIGCHI conference on Human factors in computing systems. Monterey, California, 1992, 447-453. [11] C. Lewis, J. Rieman. Task Centered User Interface Design: A Practical Introduction [Online]. Available: http://www.acm.org/~perlman/uidesign.html, 1994. [12] J. Raskin, The Human Interface. New York, Addison Wesely, 2000. [13] T.G. Holzman, “Computer-Human Interface Solutions for Emergency Medical Care,” Interactions, vol. 6, no. 3, pp. 13-24, 1999. [14] M. Wiklund, Human factors design process for medical devices: National Standard ANSI/AAMI HE74:2001. U.S. Food & Drug Administration, 2001 [15] M. Wiklund, “Making Medical Devices More User-Friendly,” Medical Device and Diagnostic Industry Magazine, vol. 5, pp. 177-186, 1998.
27
[16] E. Shortliffe, Computer-based Medical Consultations, MYCIN. New York: Elsevier, 1976. [17] G.O. Barnett, K.T. Familglietti, R.J. Kim, E.P. Hoffer, M.J. Feldam, “DXplain on the Internet,” in Proc. AMIA Symp., 1998, pp. 607-611. [18] P. Ramanarayan, A. Tomlinson, A. Rao, M. Coren, A. Winrow, J. Britto, “ISABEL: a Web-based differential diagnostic aid for paediatrics: results from an initial performance evaluation,” Archives of Disease in Childhood, vol. 88, pp. 408413, 2003. [19] P. Ramnarayan, J. Britto, “Paediatric clinical decision support systems,” Archives of Disease in Childhood, vol. 87, no. 5, pp. 361-2, 2002. [20] E. Ammenwerth, A. Buchauer, B. Bludau, R. Haux , “Mobile information and communication tools in the hospital,” International Journal of Medical Informatics, no. 57, 21-40, 2000. [21] R.N. Shiffman, B.T. Karras, “Pen-Based, Mobile Decision Support in Healthcare,” ACM SIGBIO Newsletter, vol. 19, no. 2, pp. 5-7, 1999. [22] B. Shneiderman, Designing the User Interface. Strategies for the Effective HumanComputer Interaction, 3rd ed. New York, Addison Wesley, 1998. [23] J.M. Carroll, Making Use. Scenario-based Design of Human-Computer Interactions. Cambridge: The MIT Press, 2000.
28
[24] J. Gulliksen, B. Sandblad, “Domain specific design of user interfaces,” International Journal of Human-Computer Interaction, vol. 7, no. 1, pp. 135-151, 1995. [25] J. Ostrem, Palm OS ® User Interface Guidelines [Online]. Available: http://www.palmos.com/dev/support/docs/uiguidelines.pdf, 2003. [26] W. Michalowski, S. Rubin, R. Slowinski, Sz. Wilk, “Triage of acute abdominal pain in childhood: clinical use of a Palm handheld in a pediatric Emergency Department” in Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04). Los Alamitos: IEEE, pp. 60161a (CD ROM version), 2004. [27] J.G. Anderson, S.J. Jay, “The diffusion of computer applications in medical settings,” in Use and Impact of Computers in Clinical Medicine, J.G. Anderson, S.J. Jay, Eds. New York: Springer-Verlag, 1987, pp. 2-14. [28] M.A. Counte, K.H. Kjerulff, J.C. Salloway, B.C. Campbell, “Implementing computerization in hospitals: a case study of the behavioral and attitudinal impacts of a medical information system,” in Use and Impact of Computers in Clinical Medicine, J.G. Anderson, S.J. Jay, Eds. New York: Springer-Verlag, 1987, pp. 224237. [29] M. Fieschi, J.C. Dufour, P. Staccini, J. Gouvernet, O. Bouhaddou, “Medical decision support systems: Old dilemmas and new paradigms?,” Methods of Information in Medicine, vol. 3, pp. 190-198, 2003.
29
[30] A.S. Gertner, B.L. Webber, “TraumaTIQ: Online decision support for trauma management,” IEEE Intelligent Systems, vol. 13, no. 1, pp. 32-39, 1998. [31] A. Glas, B. Pijnenburg, J. Lijmer, K. Bogaard, M. de Roos, J. Keeman, R. Butzelaar, P. Bossuyt, “Comparison of diagnostic decision rules and structured data collection in assessment of acute ankle injury,” Canadian Medical Association Journal, vol. 166, no. 6, pp. 727-733, 2002. [32] S. Guerlain, K. LeBeau, M. Thompson, C. Donnelly, H. McClelland, S. Syverud, J. Calland, “The effect of a standardized data collection form on the examination and diagnosis of patients with abdominal pain”, in Proceedings of the Human Factors and Ergonomics Society 45th Annual Meeting, Minneapolis, 2001, pp. 1284-1289.
30
Footnotes This work was supported by grants from the Natural Sciences and Engineering Research Council of Canada. Wojtek Michalowski is with the University of Ottawa, School of Management, Ottawa, Ontario, Canada (phone: 613-562-5800 x. 4955; fax: 613-562-5164; e-mail:
[email protected] ). Szymon Wilk is with the Poznan University of Technology, Institute of Computing Science, Poznan, Poland (e-mail:
[email protected]). This research was conducted while he was a Postdoctoral Fellow at the University of Ottawa. Marta Kersten is with the Queen’s University, Kingston, Ontario Canada (e-mail:
[email protected]).
Figure Captions Fig. 1. The interaction framework Fig. 2. Sample scenario of MET usage Fig. 3. The OAI model for the triage task Fig. 4. The OAI model for the interface Fig. 5. Navigation between main triage actions Fig. 6. Navigation between recording attributes Fig. 7. Recording a precise value Fig. 8. Recording an imprecise value Fig. 9. Recording a value from an infinite set Fig. 10. Recording a note Fig. 11. Evoking a triage function
