1. University of Michigan Health System: Radiology Department
MRI Lead Tech
System Design
IOE 536 Final Paper
Aalap Doshi
Linus Wooram Jeon
Michael Kabcenell
Andy Lesko
December 9th, 2008

2. TABLE OF CONTENTS
ABSTRACT ................................................................................................................................................. 1
INTRODUCTION....................................................................................................................................... 1
PROBLEM STATEMENT and PROJECT GOALS .............................................................................. 2
PROBLEM IDENTIFICATION ............................................................................................................... 2
Lead Tech Walkthrough............................................................................................................................ 2
Schedule Inpatients and Outpatients ..................................................................................................... 2
Arrival of Patient .................................................................................................................................. 3
System Feedback .................................................................................................................................. 3
Scan Completion ................................................................................................................................... 3
Scheduling................................................................................................................................................. 4
Patient Movement and Support ................................................................................................................. 5
Machine Status .......................................................................................................................................... 6
DESIGNS ..................................................................................................................................................... 7
Separate Scheduling System ..................................................................................................................... 7
Input ...................................................................................................................................................... 7
Algorithm Features ............................................................................................................................... 8
Output ................................................................................................................................................... 8
Design 1: Department Status Based Design.............................................................................................. 8
Overview............................................................................................................................................... 8
Department Status Screen ..................................................................................................................... 9
Information in Each Room.................................................................................................................... 9
Alarms and Error Handling................................................................................................................. 10
Scheduling Screen............................................................................................................................... 11
Paging Screen ..................................................................................................................................... 12
Design 2: Patient Focused Design .......................................................................................................... 12
Overview............................................................................................................................................. 12
Department Status Screen ................................................................................................................... 13
Walkthrough (Department Status Screen) .......................................................................................... 13
Alarms and Error Handling................................................................................................................. 15
Scheduling Screen............................................................................................................................... 16
Portable Device ....................................................................................................................................... 17
EVALUATION TECHNIQUES .............................................................................................................. 18
CONCLUSION ......................................................................................................................................... 19
!
!
!

3. ABSTRACT
The University of Michigan Health System MRI Department is a complex domain which handles large
amounts of information simultaneously. Due to the high patient load, the many states the MRI machines
can be in, and the potential for dangerous situations, a lot of attention must be paid to the process at all
times. The lead MRI technician is in charge of maintaining a constant flow of patients through each of the
four MRI scanning rooms, avoiding potential errors, and dealing with any issues that may arise in the
MRI process. Currently, there is no comprehensive system to aid the lead technician in her mission to
keep the MRI department running smoothly. Also, the lead technician is not able to appropriately handle
abnormal conditions such as the need for emergency patient scanning, machine quenching, missing coils,
and missing patients. We analyzed the current problems and categorized them into three main groups:
machine status, patient movement, and scheduling. Since it is assumed that scheduling automation can be
supported, we suggested two solutions in the view point of patient movement and machine status. Based
on the cognitive design rules, this paper proposes graphical interfaces that the technicians can use to keep
an eye on all relevant aspects of the MRI process, which allows her to reduce the information cost, work
load, and human errors. This interactive monitoring system is expected to speed up the process, keep
everyone on the same page, allow for faster error reporting, and generally make the immense task of
controlling all 4 MRI scanners a little more manageable.
INTRODUCTION
The University of Michigan Health System (UMHS) is one of the foremost medical institutions in the
country. It consists of a very large campus of buildings that span across both the university and the city of
Ann Arbor that house almost every conceivable facility in modern medicine. The particular area of
interest is the UMHS Radiological Department, specifically MRI. The MRI Department requires a large
amount of coordinating in order to run smoothly. Considering that the cost to run an MRI machine is
$25/minute, the implications of sub-optimal use of the resources with the department are significant. The
main person in charge of managing the MRI Department is the Lead Technician (LT). At any one time,
the LT has the task of coordinating the schedules and tasks of six technicians, two technician assistants,
six patients, as well as manage any issues that arise during normal operation of the four scanners. The
technicians’ function is to operate the scanners while the technician assistants support activity throughout
the entire department (such as relaying messages and transferring paperwork).
The LT’s main functions include scheduling patients, supporting patient movement within the
department, and knowing the overall system status. The LT has to manually make a schedule each day
that is complicated by scanner and coil availability, as well as separate requirements between inpatients
1!
!

4. and outpatients. The LT must also ensure patients are being moved smoothly from station to station to
minimize their waiting time. Lastly, the LT must have the knowledge of the overall status of the
department to be able to manage the department effectively. The LT’s are also considered the experts of
the machines, so they must know how to fix scanners if they fail or help techs run unfamiliar scans.
PROBLEM STATEMENT and PROJECT GOALS
The current set of tools available to the LT does not allow the LT to optimally manage the MRI
department and support other associated tasks. This leads to
! Inefficient use of time
! Poor operating margins
! Safety concerns
! High access cost of information
! Increased waiting time for patients
! Unsatisfied patients
! Over-staffing
The group aims to design an integrated system to provide the LT with real time updates of the system
status which will include a set of tools to support the LT in scheduling and supporting patient movement
throughout the department.
PROBLEM IDENTIFICATION
Lead Tech Walk-Through
This is a walk-through over a typical workday in the life of the Lead Tech. The process has been broken
down into the following subsections: Scheduling, Patient Arrivals, System Feedback, and Scan
Completion. A detailed process flow map is shown in Appendix A.
Scheduling Inpatients and Outpatients:
1. The Lead Tech gets scheduling lists of outpatients and inpatients that need an MRI. The lists
contain patient information, scan type, and patient priority.
2. The Lead Tech needs to schedule the out-patients and in-patients depending on:
a. Priority of patients
b. Type of scans
c. Time required for scans
d. Machine and coil availability
2!
!

5. e. Patient preparation time
f. Room preparation time
3. The lead tech comes up with a schedule for the day and writes it down on the whiteboard near her
desk.
Arrival of Patient (Inpatient or Outpatient):
1. When a patient arrives, everyone in the department receives an auditory notification over the
intercom.
2. The patient waits in the waiting room and fills out some paperwork.
3. The completed paperwork is dropped into a container near the Lead Tech’s desk .
4. The patient is gowned up in the changing rooms.
5. The Lead Tech or her assistant takes the paperwork to the individual MRI room where the patient
is scheduled to be scanned.
6. If patient is ready, the tech or Lead Tech takes the patient to the Prep. Room where they are given
the contrast agent, sedatives, etc.
7. If the patients require people form other department (anesthesiologists, nurses, doctors etc), the
Lead Tech pages the required people using the paging system near her desk.
8. Lead Tech physically checks Prep room to see if the patient is ready.
9. If they are, the Lead Tech informs the corresponding Techs to lead the patients to the appropriate
scanning room.
10. Scan begins.
System Feedback:
1. The Lead Tech physically goes to the MRI room to check how much time is left on a scan.
2. The Lead Tech is physically notified by the Techs if there is a technical difficulty or an
emergency.
Scan Completion:
1. Once the scan on a patient is complete, tech takes patient back to the changing room to change
back to their original clothes.
2. Patient then leaves.
We have used this walk-through as a means to identify the problems that the Lead Tech faces as part of
her work. The problems can basically be classified into the following three main categories:
3!
!

6. 1. Scheduling: This category addresses issues that the Lead Tech faces related to scheduling
inpatients and outpatients for MRI.
2. Patient Movement and Support: Issues related to the movement and support of patients from
the time they enter the MRI department to the time they leave the department after successfully
completing a scan are considered in this category.
3. Machine State: This category considers issues related to how the Lead Tech obtains information
regarding the machine state.
The next section describes these in detail.
Scheduling
As previously stated, one of the main functions the Lead Tech performs is scheduling. There are several
issues with the current system that cause suboptimal use of time and unnecessary cognitive input.
The first problem area is the manual scheduling requirement of the Lead Tech. The Lead Tech needs to
compile paper inpatient schedules along with outpatient schedules that can be in either paper or electronic
format. The LT also has to keep coil availability, length of scan, room availability, nurse and expert
availability, as well as several other factors in mind when generating the schedule. This process is very
rule/algorithm based as opposed to knowledge/heuristic based and could be, to a certain extent,
automated. If it did require a lot of critical thinking, analysis, and unique problem-solving, then the Lead
Tech would have to be required to compile the schedule. However, this is not the case with the current
scheduling strategy.
The second problem with the scheduling is the white board. The white board can be seen in Figure 1. The
purpose of the white board is to act as a collaborative
tool for Techs and Lead Techs to share the schedule.
There are many issues with this strategy of sharing the
schedule with the department. First, the white board is
very conducive to change blindness. If a patient’s name
was changed or if a patient rescheduled their time slot, it
would be almost impossible to tell if there was a change
made. There are no alerts/ notifications to indicate a Figure 1. White Board for scheduling
change was made.
4!
!

7. The data on the white board is available but not immediately observable. It takes a good amount of time
to search for the right time, the correct scanner, and what scan they require. Also, the scanners are listed
out of order along the top of the schedule board, which is an unnatural mapping.
The information is not clearly discriminated on the board. Almost all of the writing is in the same color,
whether it is the patient’s name, the scan required, or the Tech’s name that is on for that shift. Those
pieces of information can easily be confused when quickly looking at the schedule. There are also
numerous extraneous magnets on the board that are rarely used and cause clutter.
Next, the white board is not error or change tolerant. If someone made a mistake and erased the wrong
name, or happened to rub against it, erasing some of the schedule, there is no easy method to undo the
damage. That would require the Lead Tech to open the electronic schedule and re-write it on the board.
Each time a patient reschedules, the Lead Tech is required to erase some of the board, bump other patients
out of their slot, and rewrite the schedule. Again, this is an unnecessary strategy to make simple changes.
The last problem with the scheduling is the red emergency phone. The red phone is there to notify the
Lead Tech when a patient has arrived in the Emergency Room (ER) and needs an MRI immediately.
Although the fact that the phone is red signals its importance, there is no defense-in-depth in case the
Lead Tech is not at the desk. Especially in critical situations, the MRI department must always be
available and respond quickly. There is no set back up plan for when the Lead Tech is not there. In that
case, the ER patient will be brought down unannounced and stress resources in the department as well as
slow down the patient care.
Patient Movement and Support
The second task category which our team considered was how patient movement and support is optimized
in terms of ergonomics.
We observed that the department lacked awareness of room and patient readiness. The Lead Tech must
visit the rooms personally to check the status. This can cause asynchronies between the prepping and
scanning rooms where a patient will be ready to be scanned, but the room won’t be ready because they
thought they had more time.
5!
!

8. Our team noticed a lack of set roles of moving patients. Currently, this task is split between techs and lead
tech. This switching of responsibility only adds to the unawareness of patient or paperwork state. The
following is a list of information that LT needs to know about patient status.
Lead Tech does not have any present interface or collaborative tools. The Lead Tech needs to know
patient readiness, who is responsible for moving each patient through
the process, and the status of the paperwork. As of now, there is no
interface to provide this information, and the tools available to her are
spread out as seen in Figure 2. This makes the process from patient’s
paperwork to scanning inefficient because she needs to find each piece
of information by herself.
Figure 2. Lead Tech's workspace
Machine Status!
The third task category our team considered was how information regarding the machine state is obtained
by the LT.
Again, our team noticed a severe lack of knowledge in the world, poor visibility of system status, and
high information access costs for the LT. Below is a list of machine status information that the LT needs
to know on a routine basis:
! The location of the coils needed for upcoming scans
! Whether a machine is currently scanning
! Which scan is currently being run
! How much time is left in a scan
! Machine availability
! Emergency situations
! Patient issues while undergoing scan
! Technical issues that arise
6!
!

9. All these issues are hard to track due to the size and
configuration of the MRI department which can be seen
in Figure 3. Coils must be tracked because if a coil is in
another room and the next scan scheduled requires that
coil, it is possible that the coil may be unobtainable
because a scan is being run in the room that it is in.
Therefore, a proactive approach to tracking coils is
needed in order to avoid extensive delays. Also, not only
do the coils have to be tracked constantly, they are not Figure 3. Hallway of department
easy to locate due to the fact that the LT must enter
each room, assuming a scan isn’t being run, and actively search for the coil. This leads to a very high
information access cost that could easily be mitigated. A few simple status items that can be continually
tracked through a simple interface is whether a machine is scanning, what scan is it, and how much time
is left in the scan. These are simple stats that as of now, the LT has to physically obtain by walking to the
scanning room and asking, but could easily be tracked by an interface. Lastly, emergency situations,
patient issues, and technical issues are, while less common, are status items that must be monitored.
Unlike some of the other stats, this information is something that is not always available or needed, but if
it does occur, the information must be presented readily and saliently. This issue certainly violates the
design principle of having readily available knowledge in the world and having reminders in the world for
important things. The only way this information is transferred is by having the techs walk down to tell the
LT.
DESIGNS
This section will outline the separate scheduling system that is present in both designs, the department
status based design, the patient focused design, and a portable interface concept.
Separate Scheduling System:
We propose that there is a separate algorithm based scheduling module that does the scheduling for all
patients. This system will be implemented into the two following designs. A formal specification of the
algorithm would be as follows:
Input:
1. List of inpatients
2. List of outpatients
7!
!

10. 3. Priorities of all the patients (Low, Medium, Emergency, Etc.)
4. Scans Requested
5. Time Window, T, to Schedule Scan
6. Available coils and room availability tracked/inputted electronically without requiring any
additional input from the user
Algorithm features:
1. Schedule patients based on priorities, scans requested, inpatients vs. outpatients for a time
window T.
2. Keep track of current time and patients scanned
3. If a new emergency patient comes in, add patient to list and run algorithm again at that instance
with current time t and computing schedule for time window, T
4. If a patient of priority low or medium comes in, just add patient to list
Output:
1. Schedule of patients in list form
This output schedule will then be processed by the proposed interface and represented in various ways
mentioned.
Design 1: Department Status Based Design
Overview:
The first of our approaches to designing for the problem at hand involved focusing on Department Focus
as the main function to be covered. While the design focuses on Department Status it also covers the other
task categories – Patient Movement and Scheduling. Thus, for the first design, the interface is divided into
three sections: Status, Scheduling, and Paging as seen below in Figure 4.
Figure 4. Interface Design based on department status
!
8!
!

11. The Department Status Screen:
Figure 5. Status section
We are in the Status section of the interface highlighted by the blue color. The Status section is laid out as
the actual MRI department. The spatial arrangement of the MRI rooms as the actual MRI department
facilitates the Naturalness Principle.
The Status Based Representation is a Substitutive Representation where different colors are used to show
the qualitative differences in room status. The rooms could be one of the following colors:
1. Yellow: Yellow implies that a patient is in the room and a scan (in case of it being an MRI room)
is in progress. There is no problem with whatever is in progress in the room.
2. Green: Green implies that a room is empty and ready for the next patient.
3. Grey: Grey implies that a room is unusable. It is important to note here that it does not signify an
active error but just that a room is unusable.
The representation also supports pre-attentive reference such that it allows the Lead Tech to decide which
objects are important and need further processing before actually processing them.
Information in each room:
As Norman says, ‘A good representation is such that it needs to capture the essential elements of a
situation deliberately leaving out the rest…’ To get the right level of
abstraction into the system, we did an analysis of what were the most
important status feeds that the Lead tech required and came up with: Name,
Scan, Coil Availability and Time Left. These are represented in the first level
of the interface as seen in Figure 6. Other information that the Lead Tech
Figure 6. Information
requires, but not frequently, can be obtained by ‘mouse rollover’ over the for each MRI room
room of interest. This action was chosen as a means to minimize the
information access cost. The symbol of a person is used as a redundancy gain measure to show that a
9!
!

12. patient is present in that room. The time into a scan is an important feedback for the Lead Tech. She needs
to know how much a scan has progressed. She also needs to know exactly how much time
is remaining for a scan. Both these objectives are achieved using a Status Bar to show the
progress of a scan in a quick glance (analog
representation) and a ‘Time Left’ digital display. The
calendar symbol, in the top right corner of every MRI Figure 7.
Calendar symbol
room and shown in Figure 7, is an entry point to the
schedule only for that room. The schedule comes up as a pop-up window
where you can see the schedule as a list and in a chart form, seen in
Figure 8. You can also get to the schedule from the Scheduling section
Figure 8. Pop-up schedule but this is an attempt to reduce the information access cost.
Alarms and Error Handling:
1. Coil Missing Alarm:
It is important to raise an alarm when a coil is missing in one of the rooms. The timing of the alarm is also
important. An alarm alerting the absence of a coil in one of the rooms is
sounded 10 minutes before the corresponding scan scheduled in that room
as shown in Figure 9. The timing is such because the coil could be used in
another room before that and there is no point in sounding the alarm too
early. The alarm is a multimodal cue to facilitate data driven attention
capture and gives not only the problem with the system but also a way to Figure 9. Coil missing alarm
recover from it. The alarm is red colored flashing message in the room that is missing the coil keeping
human perceptions about the color red (as something being wrong) in mind.
Once the Lead Tech acknowledges the alarm, it is disabled. However the alarm will pop up again if time
passes and the room has still not got the coil that it needs to get the scheduled scan started. The alarm will
be louder and more prominent as the scheduled scan time comes closer. This is so taking the graded
feedback approach into consideration.
2. MRI Quenching alarm:
Quenching gets the highest priority in terms of alarms. It requires the Lead Tech to quickly go to the room
under consideration, access the situation and do the needful. It must be said that it is a very rare
occurrence. However, when it occurs, it can be very dangerous. Thus this alarm involves a loud
10!
!

13. multimodal alarm to guarantee data driven attention capture. The alarm can
be seen in Figure 10. Audio channel is supposed to be the fastest channel to
transfer attention and so it is used as a primary mode in this case. Visually,
the entire room that is quenching would blink to emphasize salience. The
alarm describes not only the fact that a MRI room is Quenching, but also
gives the room number and how to recover from the error. There is Figure 10. Quenching
alarm
heightened cognitive load on the operator in case of an emergency. All other lower priority alarms (like
!
coil missing alarms) would be disabled during this time to prevent alarm inflation.
Scheduling Screen:
In the scheduling section, shown in Figure 11, we have the schedule organized both as a list and a ‘time
Vs room’ chart. The list is used to give more details about a patient and for flexibility and filtering
options while the visual representation is
used for quick, at a glance information
capture. The list view can be used to sort
and filter information based on Patients,
Scans, Rooms, Start or End Times. Color
is used to provide feedback about patient
status. Green color implies that the patient
is ready for a scan while white implies
that a patient is scheduled but has not Figure 11. Scheduling screen
arrived yet. If a row or a slot is clicked, all information about that row/slot is displayed in the blue
information box located in the bottom. The color of the box matches the color of the highlighted row/slot.
The visual representation of the schedule acts as a DMI. If the Lead Tech needs to make any changes to
the schedule she could do it just by moving the slots and directly manipulating the interface. This helps
her to quickly know the result of her actions and focus on the task at hand making the representation
almost non-existent. The DMI based interface also helps account for the (n+1) problem as she might need
to make quick changes/arrangement for new unscheduled patients to be slotted in (Eg: High Priority ER
patients).
11!
!

14. Paging Screen:
The Lead Tech might need to page people from outside. The people she needs to page and the messages
that these pages constitute are, on the
most part fixed. The paging interface,
seen in Figure 12, allows the Lead Tech
to just page a pre-fixed number and
message by pressing the button on the
screen. This saves her time and effort in
repeatedly typing the same number and
message. She can create a new number
and page message using the New option Figure 12. Paging screen
in the top left corner.
To account for the (n+1) problem where she might need to page someone who she never has and she does
not think it worthy enough to create a new page, she can use the lower ‘Custom’ section to send these
one-off pages.
All the pre-fixed pages on the section act as a DMI. This is aimed at allowing the user to organize the
pages as she wants by moving them around. It will help in reducing the information access cost as the
Lead Tech will herself be aware of what page is where and could quickly access it.
Design 2: Patient Focused Design
Overview:
The approach taken for the second design was to target the Lead Tech’s task to facilitate patient
movement throughout the department.
The goal of this design was to increase
patient throughput for maximum
efficiency and increase patient comfort
and satisfaction. While targeting patient
movement, the design also supports
scheduling and department status tasks.
This design would require two adjacent
screens: one showing the department
Figure 13. Interface Design
12!
!

15. status screen and one displaying the schedule, which will be discussed later. The department status screen
is shown in Figure 13.
Department Status Screen:
Along the left side of the display are patient name, type of scan, and whether they are an inpatient or
outpatient. Along the top are the four stages the patient needs to complete. At a quick glance, there are
several signs and symbols that have different meanings, which will now be explained. The use of signs
and symbols are helpful in reducing the cognitive requirements of the LT.
The first piece of information the LT needs is patient location. The patient location is denoted with the
use of a sign: a yellow box with an image of a body. In order to place knowledge in the work domain, the
body image is needed so the LT does not need to remember what the color yellow means. The body
image facilitates the naturalness principle. Also, the room number is clearly shown next to the body.
The status of the patient in the room is shown with both an analog and a digital display of the time
remaining. The analog display gives at a glance information while the digital display gives an absolute
time. Both are needed, especially since each stage in the department takes a different amount of time.
Note that only the status of next patient stage is shown. This is to make the information that is crucial
more salient.
The status of the next stage is shown with a symbol: an open door and the status written in green. The
open door supports the naturalness principle. The green “Open” text helps with redundancy. It is not
required, but it aids with perception of the door symbol.
Completed stages are shown in gray with a check mark. This helps with making the important
information, such as current and upcoming patient stages, more salient.
Lastly, the LT has the ability to make edits with the blue “Edit Information” button at the bottom right of
the interface. This shows error tolerance. When this button is clicked, the LT would manually change
any information desired.
Walk-Through (Department Status Screen):
At this point, a walk-through will be given to show how the interface would function in real life.
Fifteen minutes prior to patient arrival, the patient’s row will be automatically displayed at the bottom of
the display with the blue action button “Patient Arrived.” The information pops up on the bottom to not
13!
!

16. disrupt the LT’s natural mappings and where her attention was directed. When the blue action button is
clicked, as seen in Figure 14, it means the patient has arrived and is now in the waiting room.
1. Prior to clicking “Patient Arrived” button
2. After clicking “Patient Arrived” button
3. After clicking “Paperwork Complete” button
Figure 14. Process of when a patient arrives
When the patient is in the waiting room, there is now a blue action button labeled “Paperwork Complete.”
When the LT receives the patient’s paperwork at her desk, she would then click the button and the display
would show a green “Tech Paged” indication. The style is much different than the blue action button,
showing successful clicking of the button and informative feedback.
Similar to the first design, there would be layering of information. On a mouse rollover of a patient’s
name, more information would be displayed. This is here to achieve the correct level of abstraction.
The interface is slightly independent in that updates in patient status would be automatically indicated on
the screen. For example, when a patient moves into the changing room, the tech responsible for
transporting the patient would hit a button in the changing room and the information would be
automatically reflected on the LT’s display. Time remaining would decrease based on the patient’s
expected time in the changing room. When time remaining reached zero, the system would page the tech
to transport the patient, and that information would be reflected on the interface.
Now that normal conditions and function of the interface have been detailed, cases when abnormal
conditions occur will be discussed.
14!
!

17. Alarms and Error Handling:
This section describes how the interface would react in abnormal conditions with the use of alarms. In all
of these cases, the alarms use data-driven attention allocation, to inform the LT of the issue. Also, all of
these alarms use a multimodal approach with both audio and visual cues. Audio cues are omnidirectional
to ensure the LT receives the needed information when she is tending to another task.
1. Double-booking a Room
The first abnormal condition that will be discussed is when the patient is scheduled to go into a room that
is currently occupied. The interface would look as shown below in Figure 15.
Figure 15. Scan room 2 is occupied
The symbol shows a closed door with red text, “Occupied.” At this point, a multimodal alarm would
pop up as shown below and would flash until the LT clicked the alarm, as seen in Figure 16.
Figure 16. Room conflict alarm
This alarm not only informs the LT that there is an issue, but also prompts her to select an action,
meaning the alarm is much more informative. This is an example of a feed-forward system, where the
system informs you of an upcoming issue, as opposed to waiting until the problem occurs. When the
“Room Conflict” button is clicked, a separate
display appears, as shown in Figure 17, that
allows her to address the issue. The display gives
a brief overview of what is currently happening
in the department. The status of the separate
scan rooms is shown in green and red for
information salience. It also gives information Figure 17. Room status pop-up for room selection
for how long each of the rooms is open or occupied. Again, for consistency, the action buttons are blue
and allow the LT to select a room to move the patient to. The system gives a recommended action, as
15!
!

18. opposed to executing an action in Sheridan’s Levels of Automation. The action button “Move to S2” is
gray because the patient is currently scheduled for S2 and cannot be moved there. The interface also
allows for no change with the “Do Not Move
Patient” action button.
If the LT were to follow the recommended
action and click the “Move to S4” button, the
display would look as show in Figure 18. The
information is shown in green for salience and
informative feedback, indicating successful
shift to S4. Figure 18. Room status pop-up w/ selection
2. Coil Missing Alarm
If a coil were missing from a room, a multimodal alarm would pop up when the patient was in the stage
immediately prior to the scanning, shown in Figure 19. The information
would flash until the LT brought the correct coil to the room. The alarm
does not only tell that a coil is missing, but also gives information to
allow the LT to quickly correct the situation. Figure 19. Coil missing alarm
3. MRI Quenching Alarm
The last abnormality is when the MRI is quenching, which is a potentially very dangerous situation. This
design attempts to prepare for the “n+1” problem. While quenching is a rare occurrence, it can still be
designed for. The alarm would appear as shown in
Figure 20. Because of its importance, the alarm takes
up almost the entire screen. The alarm gives the
information that S1 is quenching and also to
immediately tend to the problem. The exact actions
required are outside the scope of this project. To
avoid alarm inflation, all other alarms would be
Figure 20. Quenching alarm
disabled during this occurrence.
Scheduling Screen
As stated previously, the schedule display would be on a screen located adjacent to the status screen. It is
shown below in Figure 21.
16!
!

19. Figure 21. Scheduling screen
!
Colors are used to separate the different scanning rooms for information observability. The yellow bar
indicates what time it currently is, as does the digital display on the top of the screen. Yellow was chosen
for information observability. The bar intersects patient names that are outlined in yellow, indicating
those patients are currently being scanned. The patients in the future are outlined in blue meaning they
are not currently being scanned. For information salience and to display only pertinent information, only
the next four hours of the schedule are shown. The LT would have the ability to look further ahead. At
the bottom of the screen is required information for the LT.
This schedule is also a Direct Manipulation Interface, which allows novices to operate it and shows rapid
and reversible actions directly on the screen. The LT can click and drag patients to a desired scan room
and time. The LT would clearly see if she double-booked a room right away. Also, after the action was
complete, a pop up would ask for confirmation of the action. This is for error tolerance. This device is
designed for the “n+1” problem as well if ER patients need to be slotted in immediately.
Portable Device
Although the designed interfaces would greatly reduce the amount of time the LT is away from her desk,
she will still need to attend to issues down the hallway. Because of this, portable device has been
designed as seen below in Figure 22.
17!
!

20. Figure 22. Portable device for room status
This would be a tablet PC or possibly something smaller, such as a PDA. The design issue here is
selecting what information is crucial at a first glance. We chose to use Design 1 for the portable device
because it clearly shows the room status. With the stylus tap on one of the rooms, more information
would be displayed. The device would have sound enabled to allow for multimodal cues. It would only
be active when the LT is away from her desk.
EVALUATION TECHNIQUES
We would like to start evaluating the software along with the development phase. We would not like to
wait for the end of Development to start with the evaluation since by then it might be to late to
incorporate all the results of the evaluation. We plan to begin by performing Heuristic Evaluation
evaluating the usability, functionality and aesthetics of the interface using Jakob Nielson’s usability
principles. User Testing would be done all through the development phase. Inputs from user testing would
be processed and used to feed the development of the interface. In the earlier part of the development
phase, user testing would be carried out on low-fi prototypes (Ex: paper prototypes, wireframes etc.). As
the development phase goes on, user testing could be carried on high-fi prototypes and with the
development phase coming to an end, user testing would be carried on the actual interface. User Testing
could be accompanied by visual and vocabulary analysis. Visual Analysis would help in determining how
the visual elements of the interface work out. Vocabulary Analysis might also be an important analysis to
carry out since the MRI department uses a set of vocabulary that flows into the interface too. It would
help us verify the vocabulary used in the interface and how it matches with the users perceptions. We feel
that evaluation should be carried out along with the development of the interface and the results of the
evaluation should feed into the development phase for continuous feedback and improvement.
18!
!

21. CONCLUSION!
After identifying our problem and categorizing the issues into scheduling, patient movement, and
department status, we used this grouping to focus our designs. While the first design clearly focuses on
department status while supporting scheduling functions and patient movement, the second design
focuses on tracking patient movement while providing department status updates and scheduling
functions.
The first design makes good use of pictorial realism, has high information salience, and employs effective
information layering that allows pertinent information to be seen at a glance, but provides comprehensive,
in-depth information in a deeper layer. This separation of information does come with some inherent
access costs, but that is outweighed by the benefits of reducing clutter and excessive text. This system
also relies heavily on an automated scheduling system that, while plausible in theory, has yet to be
developed. Also, the first design lacks effective patient readiness indicators which prevent truly seamless
patient movement.
The second design does a good job of tracking patients by showing where the patients are and the time
remaining at their current position. Due to its chronological layout, the second design also supports feed-
forward feedback that alerts the LT to potential issues in a manner that is easy to see and understand. Like
the first design, the patient movement focused design also employs information layering which reduces
clutter and supports “at a glance” status updates, yet retains valuable information in the second layer. This
design, however, lacks status indicators for rooms that are not currently in use by a patient. Also, it
requires two simultaneous displays to present both the chronological patient movement display and the
scheduling component. Lastly, like the previous design, this design relies heavily on the automated
scheduling system which needs to be fully developed.
While each design has its drawbacks and perks, they both would do a respectable job of keeping the Lead
Tech in touch with her department and are both radical improvements over the current “system.” Perhaps,
after studying the systems in use and employing various evaluation techniques, effective aspects of each
system could be combined to form a hybrid system that could be customized by the Lead Tech to suit
their management style. The two different types of designs could also be more practical during certain
times of the week or night versus day shifts when there are less patients but more maintenance, or more
sedated patients being scanned. Either way, these systems effectively integrate all the tools that the Lead
Tech needs to perform her job of maintaining a smoothly running department and are a complete
representation that connects the world and its users, balancing the cognitive triad.
19!
!

22. APPENDIX A
Lead Tech Process Flow Chart
20!
!