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

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 !

!!

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!!

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!!

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!!

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

change was made.

Figure 1. White Board for scheduling

4!!

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!!

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!!

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

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.

Figure 3. Hallway of department

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!!

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!!

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

requires, but not frequently, can be obtained by ‘mouse rollover’ over the

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

Figure 6. Information for each MRI room

9!!

Figure 7. Calendar symbol

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

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

but this is an attempt to reduce the information access cost. Figure 8. Pop-up schedule

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

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.

Figure 9. Coil missing alarm

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!!

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

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.

Figure 10. Quenching alarm !

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

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.

Figure 11. Scheduling screen

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!!

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

in the top left corner. Figure 12. Paging screen

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!!

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!!

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!!

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

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

Figure 17. Room status pop-up for room selection

15!!

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

disabled during this occurrence. Figure 20. Quenching alarm

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!!

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!!

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!!

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!!

APPENDIX A

Lead Tech Process Flow Chart

20!!