PAGE 10
students from many disciplines to not only get
experience with the processes relevant to their own
area, but also to get experience communicating with
professionals from a variety of other areas. Second,
students can interact with a mix of other students,
instructors, and automated characters. Thus, a role
in a scenario with minimal interactivity (such as an
unconscious patient) can be simulated by a
workflow-based automated character. More
complex roles, meanwhile, can be played either by
students or instructors (serving as “puppet masters”
moving the scenario along). Finally, in cases where
the behavior all of the external characters may be
modeled, students can interact entirely with
automated characters. This situation offers
maximum accessibility for the student, who can
train using the scenario whenever he or she chooses.
A prototype system for EMT training is
currently under development, in collaboration with
the Department of Computing Science, Faculty of
Education, and the Interdisciplinary Health
Education Partnership conducted by the Health
Sciences Education and Research Commons. In this
training program, EMT students encounter a victim
at an accident scene, and must determine which
actions to take in order to transport the victim to a
hospital. A screenshot of this scene, implemented in
a Second Life-based prototype system, is shown in
Figure 2.
In creating a virtual world-based training
scenario, we followed the process described in
Section 2.2. First, experts in the field were asked to
describe the scenes that make up the scenario. For
each scene, the artifacts and actions were identified
and transformed into workflow diagrams. A
screenshot showing the wiki page for one such
scene is shown in Figure 3.
The MERITS system stores and accesses content
as needed, and coordinates user input with the
various interrelated workflows. The actions taken
by the student include using medical diagnostic
equipment and interacting with the accident victim.
These actions are interpreted by workflows, and the
results are conveyed through a variety of artifacts.
Most of the artifacts in this scenario are pieces of
medical equipment – a spine board, for example, or
the two-way radio in an ambulance – which are
used in treating the victim, and provide immediate
feedback. Other, larger scale, artifacts include the
victim’s vehicle and the EMT ambulance. It should
be noted that, in this case, the victim is also
considered an artifact, since it helps convey the
results of actions through its condition and location.
The implementation of each of these components in
the EMT training prototype will be briefly discussed
in detail in the following paragraphs.
At the core of the MERITS system, we have
workflows which specify a) the victim treatment
process, and b) the actions associated with each
artifact (gloves, spine board, radio, victim) in the
scenario. The high-level workflow for the victim
treatment process is shown in Figure 5, and
described in the folllowing paragraph.
Many of the components of the victim treatment
workflow – Gloves, Pulse, SpineBoard and
CallHospital – are concerned with recognizing and
recording simple actions. The MoveVictim
component ensures that the victim is on the spine
board before he can be moved to the ambulance.
The DriveToHospital component analyzes the
variables, which store previous actions, determines
whether a prerequisite action (e.g., moving the
patient into the ambulance) has been missed, and
returns an appropriate message.
The workflows that define artifact-based actions
in this process fall into two types: simple toggle
(on/off) actions and information retrieval. The
toggle actions, such as putting on gloves, register
the action with the overall process workflow and
instruct the virtual world to make the appropriate
change in the object’s appearance. The second type
of action adds information retrieval to the above
tasks. This information may be retrieved either from
a database or from an external web service. An
example of this type of workflow (for the Check
Pulse action) is shown in Figure 5.
It should be noted that, while the artifact-related
components in the victim treatment workflow may
seem quite similar to the artifact workflows just
described, they are conceptually and functionally
quite different. An artifact workflow describes the
behavior of that artifact, independent of any
processes. An artifact-related component within a
process workflow, meanwhile, describes how that
artifact's behavior – that is, the actions taken on the
artifact – relate to the process as a whole. In this
process, for example, the CheckPulse workflow
describes the behavior of a pulse oximeter (or some
other pulse-checking device). The Pulse component
of the process workflow, on the other hand,
describes the impact that checking the patient's
pulse has on the process being modeled.
Representing an action in a virtual world can
pose a variety of challenges, depending on the
affordances and capabilities provided by the virtual
world. For example, in Second Life, objects can
only be touched, worn, sat on, driven, or taken by a
player. Thus, an action such as carrying an object is
CSEDU 2010 - 2nd International Conference on Computer Supported Education
58