Mri final report

384 views
332 views

Published on

Published in: Health & Medicine, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
384
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mri final report

  1. 1. University of Michigan Health System: Radiology DepartmentMRI Lead TechSystem DesignIOE 536 Final PaperAalap DoshiLinus Wooram JeonMichael KabcenellAndy LeskoDecember 9th, 2008
  2. 2. TABLE OF CONTENTSABSTRACT ................................................................................................................................................. 1INTRODUCTION....................................................................................................................................... 1PROBLEM STATEMENT and PROJECT GOALS .............................................................................. 2PROBLEM 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 .......................................................................................................................................... 6DESIGNS ..................................................................................................................................................... 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 ....................................................................................................................................... 17EVALUATION TECHNIQUES .............................................................................................................. 18CONCLUSION ......................................................................................................................................... 19! !!
  3. 3. ABSTRACTThe University of Michigan Health System MRI Department is a complex domain which handles largeamounts of information simultaneously. Due to the high patient load, the many states the MRI machinescan be in, and the potential for dangerous situations, a lot of attention must be paid to the process at alltimes. The lead MRI technician is in charge of maintaining a constant flow of patients through each of thefour MRI scanning rooms, avoiding potential errors, and dealing with any issues that may arise in theMRI process. Currently, there is no comprehensive system to aid the lead technician in her mission tokeep the MRI department running smoothly. Also, the lead technician is not able to appropriately handleabnormal 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 besupported, we suggested two solutions in the view point of patient movement and machine status. Basedon the cognitive design rules, this paper proposes graphical interfaces that the technicians can use to keepan eye on all relevant aspects of the MRI process, which allows her to reduce the information cost, workload, and human errors. This interactive monitoring system is expected to speed up the process, keepeveryone on the same page, allow for faster error reporting, and generally make the immense task ofcontrolling all 4 MRI scanners a little more manageable.INTRODUCTIONThe University of Michigan Health System (UMHS) is one of the foremost medical institutions in thecountry. It consists of a very large campus of buildings that span across both the university and the city ofAnn Arbor that house almost every conceivable facility in modern medicine. The particular area ofinterest is the UMHS Radiological Department, specifically MRI. The MRI Department requires a largeamount 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. Themain 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. Thetechnicians’ function is to operate the scanners while the technician assistants support activity throughoutthe entire department (such as relaying messages and transferring paperwork).The LT’s main functions include scheduling patients, supporting patient movement within thedepartment, and knowing the overall system status. The LT has to manually make a schedule each daythat is complicated by scanner and coil availability, as well as separate requirements between inpatients 1!!
  4. 4. and outpatients. The LT must also ensure patients are being moved smoothly from station to station tominimize their waiting time. Lastly, the LT must have the knowledge of the overall status of thedepartment to be able to manage the department effectively. The LT’s are also considered the experts ofthe machines, so they must know how to fix scanners if they fail or help techs run unfamiliar scans.PROBLEM STATEMENT and PROJECT GOALSThe current set of tools available to the LT does not allow the LT to optimally manage the MRIdepartment 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-staffingThe group aims to design an integrated system to provide the LT with real time updates of the systemstatus which will include a set of tools to support the LT in scheduling and supporting patient movementthroughout the department.PROBLEM IDENTIFICATIONLead Tech Walk-ThroughThis is a walk-through over a typical workday in the life of the Lead Tech. The process has been brokendown into the following subsections: Scheduling, Patient Arrivals, System Feedback, and ScanCompletion. 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. 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 ofher work. The problems can basically be classified into the following three main categories: 3!!
  6. 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.SchedulingAs previously stated, one of the main functions the Lead Tech performs is scheduling. There are severalissues 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 tocompile paper inpatient schedules along with outpatient schedules that can be in either paper or electronicformat. The LT also has to keep coil availability, length of scan, room availability, nurse and expertavailability, as well as several other factors in mind when generating the schedule. This process is veryrule/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 LeadTech would have to be required to compile the schedule. However, this is not the case with the currentscheduling strategy.The second problem with the scheduling is the white board. The white board can be seen in Figure 1. Thepurpose of the white board is to act as a collaborativetool for Techs and Lead Techs to share the schedule.There are many issues with this strategy of sharing theschedule with the department. First, the white board isvery conducive to change blindness. If a patient’s namewas changed or if a patient rescheduled their time slot, itwould be almost impossible to tell if there was a changemade. There are no alerts/ notifications to indicate a Figure 1. White Board for schedulingchange was made. 4!!
  7. 7. The data on the white board is available but not immediately observable. It takes a good amount of timeto search for the right time, the correct scanner, and what scan they require. Also, the scanners are listedout 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. Thosepieces of information can easily be confused when quickly looking at the schedule. There are alsonumerous 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 wrongname, or happened to rub against it, erasing some of the schedule, there is no easy method to undo thedamage. 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 patientsout 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 theLead 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 theLead Tech is not at the desk. Especially in critical situations, the MRI department must always beavailable and respond quickly. There is no set back up plan for when the Lead Tech is not there. In thatcase, the ER patient will be brought down unannounced and stress resources in the department as well asslow down the patient care.Patient Movement and SupportThe second task category which our team considered was how patient movement and support is optimizedin terms of ergonomics.We observed that the department lacked awareness of room and patient readiness. The Lead Tech mustvisit the rooms personally to check the status. This can cause asynchronies between the prepping andscanning rooms where a patient will be ready to be scanned, but the room won’t be ready because theythought they had more time. 5!!
  8. 8. Our team noticed a lack of set roles of moving patients. Currently, this task is split between techs and leadtech. This switching of responsibility only adds to the unawareness of patient or paperwork state. Thefollowing 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 knowpatient readiness, who is responsible for moving each patient throughthe process, and the status of the paperwork. As of now, there is nointerface to provide this information, and the tools available to her arespread out as seen in Figure 2. This makes the process from patient’spaperwork to scanning inefficient because she needs to find each pieceof information by herself. Figure 2. Lead Techs workspace Machine Status!The third task category our team considered was how information regarding the machine state is obtainedby the LT.Again, our team noticed a severe lack of knowledge in the world, poor visibility of system status, andhigh information access costs for the LT. Below is a list of machine status information that the LT needsto 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. 9. All these issues are hard to track due to the size andconfiguration of the MRI department which can be seenin Figure 3. Coils must be tracked because if a coil is inanother room and the next scan scheduled requires thatcoil, it is possible that the coil may be unobtainablebecause a scan is being run in the room that it is in.Therefore, a proactive approach to tracking coils isneeded in order to avoid extensive delays. Also, not onlydo the coils have to be tracked constantly, they are not Figure 3. Hallway of departmenteasy to locate due to the fact that the LT must entereach room, assuming a scan isn’t being run, and actively search for the coil. This leads to a very highinformation access cost that could easily be mitigated. A few simple status items that can be continuallytracked through a simple interface is whether a machine is scanning, what scan is it, and how much timeis left in the scan. These are simple stats that as of now, the LT has to physically obtain by walking to thescanning 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 ifit does occur, the information must be presented readily and saliently. This issue certainly violates thedesign principle of having readily available knowledge in the world and having reminders in the world forimportant things. The only way this information is transferred is by having the techs walk down to tell theLT.DESIGNSThis section will outline the separate scheduling system that is present in both designs, the departmentstatus 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 allpatients. This system will be implemented into the two following designs. A formal specification of thealgorithm would be as follows:Input: 1. List of inpatients 2. List of outpatients 7!!
  10. 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 userAlgorithm 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 formThis output schedule will then be processed by the proposed interface and represented in various waysmentioned.Design 1: Department Status Based DesignOverview:The first of our approaches to designing for the problem at hand involved focusing on Department Focusas the main function to be covered. While the design focuses on Department Status it also covers the othertask categories – Patient Movement and Scheduling. Thus, for the first design, the interface is divided intothree sections: Status, Scheduling, and Paging as seen below in Figure 4. Figure 4. Interface Design based on department status! 8!!
  11. 11. The Department Status Screen: Figure 5. Status sectionWe are in the Status section of the interface highlighted by the blue color. The Status section is laid out asthe actual MRI department. The spatial arrangement of the MRI rooms as the actual MRI departmentfacilitates the Naturalness Principle.The Status Based Representation is a Substitutive Representation where different colors are used to showthe 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 whichobjects 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 asituation deliberately leaving out the rest…’ To get the right level ofabstraction into the system, we did an analysis of what were the mostimportant status feeds that the Lead tech required and came up with: Name,Scan, Coil Availability and Time Left. These are represented in the first levelof the interface as seen in Figure 6. Other information that the Lead Tech Figure 6. Informationrequires, but not frequently, can be obtained by ‘mouse rollover’ over the for each MRI roomroom of interest. This action was chosen as a means to minimize theinformation access cost. The symbol of a person is used as a redundancy gain measure to show that a 9!!
  12. 12. patient is present in that room. The time into a scan is an important feedback for the Lead Tech. She needsto know how much a scan has progressed. She also needs to know exactly how much timeis 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 alsoimportant. An alarm alerting the absence of a coil in one of the rooms issounded 10 minutes before the corresponding scan scheduled in that roomas shown in Figure 9. The timing is such because the coil could be used inanother room before that and there is no point in sounding the alarm tooearly. The alarm is a multimodal cue to facilitate data driven attentioncapture and gives not only the problem with the system but also a way to Figure 9. Coil missing alarmrecover from it. The alarm is red colored flashing message in the room that is missing the coil keepinghuman 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 timepasses and the room has still not got the coil that it needs to get the scheduled scan started. The alarm willbe louder and more prominent as the scheduled scan time comes closer. This is so taking the gradedfeedback 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 roomunder consideration, access the situation and do the needful. It must be said that it is a very rareoccurrence. However, when it occurs, it can be very dangerous. Thus this alarm involves a loud 10!!
  13. 13. multimodal alarm to guarantee data driven attention capture. The alarm canbe seen in Figure 10. Audio channel is supposed to be the fastest channel totransfer 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. Thealarm describes not only the fact that a MRI room is Quenching, but alsogives the room number and how to recover from the error. There is Figure 10. Quenching alarmheightened 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 ‘timeVs room’ chart. The list is used to give more details about a patient and for flexibility and filteringoptions while the visual representation isused for quick, at a glance informationcapture. The list view can be used to sortand filter information based on Patients,Scans, Rooms, Start or End Times. Coloris used to provide feedback about patientstatus. Green color implies that the patientis ready for a scan while white impliesthat a patient is scheduled but has not Figure 11. Scheduling screenarrived yet. If a row or a slot is clicked, all information about that row/slot is displayed in the blueinformation 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 tothe schedule she could do it just by moving the slots and directly manipulating the interface. This helpsher to quickly know the result of her actions and focus on the task at hand making the representationalmost non-existent. The DMI based interface also helps account for the (n+1) problem as she might needto make quick changes/arrangement for new unscheduled patients to be slotted in (Eg: High Priority ERpatients). 11!!
  14. 14. Paging Screen:The Lead Tech might need to page people from outside. The people she needs to page and the messagesthat these pages constitute are, on themost part fixed. The paging interface,seen in Figure 12, allows the Lead Techto just page a pre-fixed number andmessage by pressing the button on thescreen. This saves her time and effort inrepeatedly typing the same number andmessage. She can create a new numberand page message using the New option Figure 12. Paging screenin the top left corner.To account for the (n+1) problem where she might need to page someone who she never has and she doesnot think it worthy enough to create a new page, she can use the lower ‘Custom’ section to send theseone-off pages.All the pre-fixed pages on the section act as a DMI. This is aimed at allowing the user to organize thepages as she wants by moving them around. It will help in reducing the information access cost as theLead Tech will herself be aware of what page is where and could quickly access it.Design 2: Patient Focused DesignOverview:The approach taken for the second design was to target the Lead Tech’s task to facilitate patientmovement throughout the department.The goal of this design was to increasepatient throughput for maximumefficiency and increase patient comfortand satisfaction. While targeting patientmovement, the design also supportsscheduling and department status tasks.This design would require two adjacentscreens: one showing the department Figure 13. Interface Design 12!!
  15. 15. status screen and one displaying the schedule, which will be discussed later. The department status screenis 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 oroutpatient. Along the top are the four stages the patient needs to complete. At a quick glance, there areseveral signs and symbols that have different meanings, which will now be explained. The use of signsand 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 theuse of a sign: a yellow box with an image of a body. In order to place knowledge in the work domain, thebody image is needed so the LT does not need to remember what the color yellow means. The bodyimage 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 timeremaining. The analog display gives at a glance information while the digital display gives an absolutetime. 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 crucialmore salient.The status of the next stage is shown with a symbol: an open door and the status written in green. Theopen door supports the naturalness principle. The green “Open” text helps with redundancy. It is notrequired, but it aids with perception of the door symbol.Completed stages are shown in gray with a check mark. This helps with making the importantinformation, 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 ofthe interface. This shows error tolerance. When this button is clicked, the LT would manually changeany 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 ofthe display with the blue action button “Patient Arrived.” The information pops up on the bottom to not 13!!
  16. 16. disrupt the LT’s natural mappings and where her attention was directed. When the blue action button isclicked, 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 arrivesWhen 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 displaywould 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’sname, 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 onthe screen. For example, when a patient moves into the changing room, the tech responsible fortransporting the patient would hit a button in the changing room and the information would beautomatically reflected on the LT’s display. Time remaining would decrease based on the patient’sexpected time in the changing room. When time remaining reached zero, the system would page the techto 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 abnormalconditions occur will be discussed. 14!!
  17. 17. Alarms and Error Handling:This section describes how the interface would react in abnormal conditions with the use of alarms. In allof these cases, the alarms use data-driven attention allocation, to inform the LT of the issue. Also, all ofthese alarms use a multimodal approach with both audio and visual cues. Audio cues are omnidirectionalto ensure the LT receives the needed information when she is tending to another task.1. Double-booking a RoomThe first abnormal condition that will be discussed is when the patient is scheduled to go into a room thatis 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 wouldpop up as shown below and would flash until the LT clicked the alarm, as seen in Figure 16. Figure 16. Room conflict alarmThis 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 thesystem informs you of an upcoming issue, as opposed to waiting until the problem occurs. When the“Room Conflict” button is clicked, a separatedisplay appears, as shown in Figure 17, thatallows her to address the issue. The display givesa brief overview of what is currently happeningin the department. The status of the separatescan rooms is shown in green and red forinformation salience. It also gives information Figure 17. Room status pop-up for room selectionfor how long each of the rooms is open or occupied. Again, for consistency, the action buttons are blueand allow the LT to select a room to move the patient to. The system gives a recommended action, as 15!!
  18. 18. opposed to executing an action in Sheridan’s Levels of Automation. The action button “Move to S2” isgray because the patient is currently scheduled for S2 and cannot be moved there. The interface alsoallows for no change with the “Do Not MovePatient” action button.If the LT were to follow the recommendedaction and click the “Move to S4” button, thedisplay would look as show in Figure 18. Theinformation is shown in green for salience andinformative feedback, indicating successfulshift to S4. Figure 18. Room status pop-up w/ selection2. Coil Missing AlarmIf a coil were missing from a room, a multimodal alarm would pop up when the patient was in the stageimmediately prior to the scanning, shown in Figure 19. The informationwould flash until the LT brought the correct coil to the room. The alarmdoes not only tell that a coil is missing, but also gives information toallow the LT to quickly correct the situation. Figure 19. Coil missing alarm3. MRI Quenching AlarmThe last abnormality is when the MRI is quenching, which is a potentially very dangerous situation. Thisdesign attempts to prepare for the “n+1” problem. While quenching is a rare occurrence, it can still bedesigned for. The alarm would appear as shown inFigure 20. Because of its importance, the alarm takesup almost the entire screen. The alarm gives theinformation that S1 is quenching and also toimmediately tend to the problem. The exact actionsrequired are outside the scope of this project. Toavoid alarm inflation, all other alarms would be Figure 20. Quenching alarmdisabled during this occurrence.Scheduling ScreenAs stated previously, the schedule display would be on a screen located adjacent to the status screen. It isshown below in Figure 21. 16!!
  19. 19. Figure 21. Scheduling screen!Colors are used to separate the different scanning rooms for information observability. The yellow barindicates what time it currently is, as does the digital display on the top of the screen. Yellow was chosenfor information observability. The bar intersects patient names that are outlined in yellow, indicatingthose patients are currently being scanned. The patients in the future are outlined in blue meaning theyare not currently being scanned. For information salience and to display only pertinent information, onlythe next four hours of the schedule are shown. The LT would have the ability to look further ahead. Atthe 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 rapidand reversible actions directly on the screen. The LT can click and drag patients to a desired scan roomand time. The LT would clearly see if she double-booked a room right away. Also, after the action wascomplete, a pop up would ask for confirmation of the action. This is for error tolerance. This device isdesigned for the “n+1” problem as well if ER patients need to be slotted in immediately.Portable DeviceAlthough 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 beendesigned as seen below in Figure 22. 17!!
  20. 20. Figure 22. Portable device for room statusThis would be a tablet PC or possibly something smaller, such as a PDA. The design issue here isselecting what information is crucial at a first glance. We chose to use Design 1 for the portable devicebecause it clearly shows the room status. With the stylus tap on one of the rooms, more informationwould be displayed. The device would have sound enabled to allow for multimodal cues. It would onlybe active when the LT is away from her desk.EVALUATION TECHNIQUESWe would like to start evaluating the software along with the development phase. We would not like towait for the end of Development to start with the evaluation since by then it might be to late toincorporate all the results of the evaluation. We plan to begin by performing Heuristic Evaluationevaluating the usability, functionality and aesthetics of the interface using Jakob Nielson’s usabilityprinciples. User Testing would be done all through the development phase. Inputs from user testing wouldbe processed and used to feed the development of the interface. In the earlier part of the developmentphase, user testing would be carried out on low-fi prototypes (Ex: paper prototypes, wireframes etc.). Asthe development phase goes on, user testing could be carried on high-fi prototypes and with thedevelopment phase coming to an end, user testing would be carried on the actual interface. User Testingcould be accompanied by visual and vocabulary analysis. Visual Analysis would help in determining howthe visual elements of the interface work out. Vocabulary Analysis might also be an important analysis tocarry out since the MRI department uses a set of vocabulary that flows into the interface too. It wouldhelp us verify the vocabulary used in the interface and how it matches with the users perceptions. We feelthat evaluation should be carried out along with the development of the interface and the results of theevaluation should feed into the development phase for continuous feedback and improvement. 18!!
  21. 21. CONCLUSION!After identifying our problem and categorizing the issues into scheduling, patient movement, anddepartment status, we used this grouping to focus our designs. While the first design clearly focuses ondepartment status while supporting scheduling functions and patient movement, the second designfocuses on tracking patient movement while providing department status updates and schedulingfunctions.The first design makes good use of pictorial realism, has high information salience, and employs effectiveinformation 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 inherentaccess costs, but that is outweighed by the benefits of reducing clutter and excessive text. This systemalso relies heavily on an automated scheduling system that, while plausible in theory, has yet to bedeveloped. Also, the first design lacks effective patient readiness indicators which prevent truly seamlesspatient movement.The second design does a good job of tracking patients by showing where the patients are and the timeremaining 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. Likethe first design, the patient movement focused design also employs information layering which reducesclutter and supports “at a glance” status updates, yet retains valuable information in the second layer. Thisdesign, however, lacks status indicators for rooms that are not currently in use by a patient. Also, itrequires two simultaneous displays to present both the chronological patient movement display and thescheduling component. Lastly, like the previous design, this design relies heavily on the automatedscheduling 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 LeadTech 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 eachsystem could be combined to form a hybrid system that could be customized by the Lead Tech to suittheir management style. The two different types of designs could also be more practical during certaintimes of the week or night versus day shifts when there are less patients but more maintenance, or moresedated patients being scanned. Either way, these systems effectively integrate all the tools that the LeadTech needs to perform her job of maintaining a smoothly running department and are a completerepresentation that connects the world and its users, balancing the cognitive triad. 19!!
  22. 22. APPENDIX ALead Tech Process Flow Chart 20!!

×