INFO-I 564 Indiana University Indianapolis

WheelChase Saving Time and Money for Healthcare

Michael Downey Steven Entezari 5/6/2011

2

CONTENTS

Introduction and Vision ........................................................................................................................................................ 3

Functional Design Concepts ................................................................................................................................................ 4

Web Application/Smartphone ...................................................................................................................................... 4

SMS/Pager ............................................................................................................................................................................. 5

Voice Phone ........................................................................................................................................................................... 6

Early Ideation and Prototypes ........................................................................................................................................... 7

Informal Walkthroughs ....................................................................................................................................................... 10

Medium-Fidelity Prototypes ............................................................................................................................................. 13

Prototype Usability Tests ................................................................................................................................................... 14

Potential Improvements ................................................................................................................................................ 16

Lessons Learned and Implications of Use ................................................................................................................... 18

Appendix A: Mobile Web Prototype Screens ............................................................................................................. 20

Appendix B: Web Application Prototype Screens .................................................................................................... 31

3

INTRODUCTION AND VISION

In hospitals, wheelchairs are just as commonplace as patients. Unfortunately, due to budget

and space concerns, there are not enough wheelchairs for each patient. This means wheelchairs are

used only during patient transport, then made available to anyone once no longer utilized. In an

ideal world, this method works perfectly. However, since the supply is low while demand is high,

wheelchairs are constantly being pushed around to different parts of a hospital; making it difficult

to immediately locate one when needed. In addition, hospital workers adopt a behavior where they

attempt to plan for upcoming needs, leading to wheelchair hoarding and hiding as a common

occurrence.

WheelChase is a service that enables users to locate a wheelchair within their vicinity based

upon the chairs availability. Hidden wheelchairs cannot help patients. Enabling staff to locate

available wheelchairs quickly and easily resolves this issue by making availability and location

available to anyone who needs a wheelchair. This not only reduces the hoarding of wheelchairs, but

also reduces the time it takes to locate a wheelchair and return it to a patient who needs it. Also, by

keeping track of a wheelchair’s location theft levels may reduce as well. The average cost for a

standard, hospital wheelchair is from two hundred to five hundred dollars per chair, depending on

the type of chair desired. Interviews with nurses and hospital administrators indicate wheelchair

theft is more common than people think.

4

FUNCTIONAL DESIGN CONCEPTS

WheelChase utilizes multiple Wi-Fi access points from around the hospital to triangulate its

location. All wheelchairs will be fitted with Wi-Fi transmitters, with unique identifiers, to allow a

backend database to keep track of properties relating to the wheelchair, such as type, availability,

status, maintenance dates, cleaning dates, and more. The service will be made accessible via

smartphone, web application, SMS/pagers, and voice phones. The web application will allow for

administrative users to see more than simple type and status (availability), enabling them to

maintain wheelchairs.

WheelChase is designed around a hospital’s current set of wheelchairs and existing Wi-Fi

network. Current wheelchairs would be retrofitted with a spring-loaded weight sensor to

determine if someone is sitting in that chair, which would indicate its availability (or lack thereof).

For instance, if a wheelchair has over twenty-five pounds of weight on it, a signal will be sent via the

Wi-Fi transmitter to notify the database that the wheelchair is no longer available. This sensor

would be placed beneath the seat of the wheelchair, not affecting the comfort of the seated patient.

If necessary, an additional sensor could be placed on the back of the wheelchair, to enhance the

validity of the availability status.

WEB APPLICATION/SMARTPHONE

The smartphone and web application will be hosted on a secure server, requiring proper

authentication to access its resources. The interface allows users to identify what type of chair they

need (adult, child, wide, tall, etc.), what floor you wish to locate a chair on, and for the web-app

specifically, the ability to query all chairs for any property. More specific examples of these

interfaces will be shown later in this paper.

5

SMS/PAGER

Users will be able to ping the location of a wheelchair using the SMS protocol on their

phones or two-way pagers. In the initial text, a location is provided, along with any type of filters

one may desire to include (such as the specific type of wheelchair requested). Given that the

location can be matched to the back end database, the closest wheelchairs to that location are

returned to the user via an SMS response. A more specific flowchart of an SMS scenario is located

below, in Figure 1.

FIGURE 1 - SMS FLOWCHART

6

VOICE PHONE

Users need not have a smartphone or text-service to locate a wheelchair. Using a hospital

phone, users can locate a wheelchair closest to them by simply dialing a number specific to that

hospital. The backend database will match the extension of the hospital phone with the closest

wheelchairs in its proximity. If the user is not using a hospital phone, then a step will be added to

enable the user to provide a location to the service (either specific room number or landmark like

Cafeteria or Waiting Room). A more specific flowchart of a voice phone scenario is located below.

FIGURE 2 - VOICE PHONE FLOWCHART

7

EARLY IDEATION AND PROTOTYPES

In our phases of early ideation, we focused heavily on the physical possibility of this service

even being designed. Before we began sketching the interfaces that would be utilized, we sketched

how the device would be physically implemented into the wheelchair. For the majority of

wheelchairs that have rubber handles, we designed a device that simply fit right into the hollow

rubber handle, as shown in Figure 3.

FIGURE 3 - WHEELCHAIR HANDLE

As we sketched the initial prototypes of our mobile web interface, our goal was to ensure

that the interface menus were as easy to navigate as possible. People in hospitals are extremely

busy and have absolutely no time to fight poor system design. Early sketches also gave insight to

how we envisioned the chairs being located. At first, we considered a navigational system that

would tell people how far away the wheelchairs were and guide them to that destination. However,

as we discussed alternative usage scenarios, we eventually favored a map interface would allow

easy distinction of the wheelchairs location in relation to the users -- our assumption being that

users may not necessarily want to find the wheelchairs closest to where they were at that moment,

but rather where they might be in the near future. Further, landmarks on the map would enable

users to locate the closest chair with greater ease.

Wi-Fi Transmitter

RFID Transmitter

Battery

Rubber Handle

8

We developed a video to describe this potential mobile usage. It is available online at

YouTube: http://www.youtube.com/watch?v=R1itQQ2Rlpg

Figures 4 through 6 are indicative of some of our early concepts.

FIGURE 4 - EASY TO NAVIGATE MENUS

9

FIGURE 5 - CONSISTENCY AMONGST MENUS

FIGURE 6 – MAPS

10

INFORMAL WALKTHROUGHS

We conducted several informal cognitive walkthroughs of our initial prototypes.

Fortunately, both designers had some domain expertise, with one of us having been a hospital

volunteer and one of us having spent extensive time in hospitals as a child due to his parents'

employment there. Thus, we were able to interrogate each other to ensure validity of our ideas. We

also asked several people familiar with hospitals, either as patients or health care professionals,

about their ideas of the project.

Everyone we spoke with had experienced "orphaned" wheelchairs in random places around

hospitals, such as shown in Figure 7, although those without professional experience in the hospital

environment did not have first-hand understanding of the problem finding wheelchairs. However,

when we explained the problem space to them, they immediately understood the value a

technology-based system could provide.

FIGURE 7 – ORPHANED WHEELCHAIR

11

We first set about validating our ideas on the onboard tracking unit. Although this was not

our primary design objective, we needed to understand its potential capabilities in order to design a

human interface around it. Based on concerns expressed about potential wheelchair theft, we

decided the unit should be somewhat covert. We also confirmed through both discussions and in-

person visits that hospitals with Wi-Fi networks have many access points throughout the hospital,

making a good "grid" of location receivers. Charging could happen via a small solar panel on the top

of the handlebar grip, since hospital corridors are always lit.

At first, we had intended to only design a web-based system for mobile phones. However, as

our discussions were conducted, we realized that different hospital personnel have different means

of accessing information. Many of those people are still using two-way pagers, for example. We also

discovered that many nurses work at a stationary nurses station with PC's. (Additionally, we had

not planned for a system to manage wheelchair inventory and add them to the tracking system via

the mobile application.) It was also possible, we found, that personnel might need to find a

wheelchair unexpectedly, and without any other method, may want to pick up a phone to find one.

Thus, we went back to sketch out some early conceptual models of these modes, as is shown in

Figure 8.

12

FIGURE 8 – SUBSEQUENT IDEATION FOR MULTIPLE MODES

With those additional scenarios confirmed, we set out to design additional modes to answer

the same question: "Where are the available wheelchairs nearest to me?"

13

MEDIUM-FIDELITY PROTOTYPES

We built fully designed (in terms of functionality) medium-fidelity (in terms of visual

design) prototypes of not only the mobile web application, but also a traditional web app, using

Balsamiq Mockups. Testing, described in the following section, was conducted using a combination

of clickable PDF documents and paper printouts of these prototypes. For our SMS/pager mode and

our voice mode, we designed detailed flowcharts describing how these applications would work,

since we would test them via actual SMS or a voice-only "Wizard of Oz" technique.

Appendices A and B, at the end of this document, show a selection of the mobile web app

and traditional web app screens. The diagrams of the SMS and voice modalities are included under

"Functional Design Concepts".

14

PROTOTYPE USABILITY TESTS

We conducted usability testing for all four modes with four users, resulting in 16 tests.

Participants were stratified in an attempt to capture a wide variety of potential backgrounds who

might use the system in a hospital:

1. User A: Female, age 23, college-educated and working in marketing

2. User B: Female, age 64, a retired hospital secretary

3. User C: Male, age 18, a soon-to-graduate high school student

4. User D: Female, age 21, a college student

The user was provided a background on the usage of the system and the problem space. They

were then presented the four modes in random order:

The web application was tested using the prototype images, and the user given scenarios

for both a “normal” user as well as an administrator with a separate “account” (two

separate sub-tasks).

The mobile application web tested using the prototype images as well, and the user

instructed to share his or her location with the system when prompted.

The SMS application was tested by sending and receiving actual SMS messages with the

user, as the test conductor followed the flowchart.

The voice application was tested using the “Wizard of Oz” technique, while the user, holding

a mobile phone, spoke to the “system”. The test conductor responded based on the

flowchart.

Interestingly, tests did not uncover any major stumbling points in the applications'

functionality. All users were able to complete the tasks successfully without assistance. This

15

relatively unusual situation is likely due to the simplicity of the system's goal -- providing the user

with the location and number of wheelchairs closest to him or her.

Despite the unimpaired success of our users, they did provide interesting and valuable feedback

for us, confirming some of our expectations and raising some new questions. Some of the feedback

we received at the conclusion of testing included:

"So how exactly does this know where the wheelchairs are?" This question indicates

something we overlooked, that users may not necessarily understand how the system

works and that the wheelchairs’ locations are updated automatically by the handlebar units.

In-application descriptions or help screens could provide this context, particularly

important for new users.

"This would be a lot faster than walking around the hospital to look for wheelchairs."

This comment vindicated our design ideation that a system such as WheelChase would save

time, and hopefully would be indicative of all users of the system.

"If I don’t know where I'm located on this map, how would I know what is closest to me?

It wouldn't be as useful." This comment suggested a hypothetical scenario where the user

may be using the traditional web application, but may not understand her physical location

in the hospital. This could be a possibility in the real world, depending on how the system is

used. For example, someone could log on to a computer in a different work area and not

instantly recognize their location on the map in order to find the closest wheelchairs. The

map could be revised to help recover from this scenario.

"I like that I could just send a quick text message instead of messing around with a

computer." With this comment, we were happy to see that we did go about designing the

other modes, as it would appear that people have personal preferences about which

interface style to use.

16

"So if I use this system all day, what else is it tracking about me?" This question seems to

refer to the prompt in the mobile web site about sharing location with the application, and

probably represents a larger concern by computer users about location-based services. It is

important to be sensitive to these concerns, particularly when one's employer is the one

asking for location information: users may not be comfortable telling their "boss" where

they are at any given moment.

POTENTIAL IMPROVEMENTS

Based on these comments, we would suggest the following minor adjustments to the product:

1. Provide text labels on the web map representing major landmarks. Our prototype did not

include any text on the map, and doing so could help orient the user, particularly for the

traditional web application, as that user does not have the added assistance of Wi-Fi and

GPS location such as the mobile user, or the location lookup concept of the voice user.

2. Add additional (but short) voice cues to the beginning of the voice system's introduction. If

voice users are not accustomed to using WheelChase, they may not recall what they need to

say in order to activate the system. Another possibility is that people may reach the number

incorrectly. We would suggest something like "This is WheelChase, helping you find

wheelchairs at Niles Memorial Hospital. Where do you need a wheelchair?"

3. Help screens should be developed to describe the system's functionality at a basic level and

how their location is used (and not used).

17

DESIGN WISHLIST

The possibilities and potential of Wheelchase will grow with more time and resources.

During discussions, brainstorming episodes, and drafting exercises ideas were derived that were

outside of the scope for this particular project but beneficial for future research. A few of the ideas

are noted below:

1. Patient Monitoring with Wheelchair a. During the use of a wheelchair, there are three main stakeholders; patient,

wheelchair-pusher, and wheelchair. In the event that the patient and wheelchair are

separated from their designated hospital wheelchair-pusher, a system could be

utilized that monitors patients via RFID tags in their hospital bracelets, matched

with the wheelchairs Wheelchase RFID and Wi-Fi system, to locate the patient.

Episodes like this, while not terribly common, can be beneficial for the instances

that a patient is unable to move for a pre-determined amount of time. A hospital

worker will be able to locate the individuals last location to the wheelchair and

provide any assistance needed.

2. Wheelchair Route Planning a. Users who need a wheelchair may not need one in their current location. For

instance, if a nurse is going from the second floor, west wing to pick up a patient

from the fourth floor, east wing, a wheelchair along the route to the fourth floor, or

on the fourth floor, may be the best option for speed and efficiency.

3. Wheelchair Delivery Service a. In bigger hospitals, there may be a bigger volunteer base. Many hospitals currently

have a volunteer position solely responsible for transporting patients from one

location of the hospital to another in a wheelchair. An addition to our current

interface would be the ability to schedule this process via a smart phone or any

other modality listed in this report.

18

LESSONS LEARNED AND IMPLICATIONS OF USE

As demonstrated, WheelChase would enhance current hospital protocols and reduce

undesired behaviors such as wheelchair hoarding and hiding. When you take away the problem of

being able to find a wheelchair, you take away the adaptations to that problem, such as the

behaviors mentioned before. However, as to be expected with paradigm shifts via automating

portions of previously manual tasks, some unforeseen and even undesired consequences were

noted.

If a nurse needs a wheelchair today, before the implementation of WheelChase, the nurse

must first look in the immediate area, then begin walking around the hospital, searching for

available wheelchairs. Since this is a common occurrence, a predefined path, or usual path, may be

established in one’s mind based upon where one has found wheelchairs in the past. Along the route

the nurse may take, other instances may occur that the nurse can either help with or utilize for help

in another situation. An example of this could be noticing that the west wing is overcrowded, that

there is a spill on the floor, or that over half of a unit is filled with patients suffering from a similar

condition to that of that nurse’s patient.

Related to the “usual path” problem listed above, we also identified a breakdown in the

social structure of the hospital environment. Looking for a wheelchair may prove to be a two-fold

benefit to someone looking for one. In one case, it helps them find the wheelchair. In another, it

allows them a chance to get away and socialize with other hospital employees. In hospitals, nurses

are usually assigned a station and a set of patients. While there is some interaction amongst nurses

during the day for practical purposes, there aren’t that many chances for them to socialize with one

another. At times, when a nurse may want to get away and go for a walk, an excuse they may use is

that they went to “look for a wheelchair”. While this is not efficiently great, it might possibly be a

huge morale component that reduces stress levels on a twelve hour shift.

19

Also, individuals may be skeptical at the idea of tracking wheelchairs throughout a hospital.

While no patient information will be recorded via WheelChase, the stigma of knowing others can

pinpoint your location may induce a sense of fear. Public education and training on the WheelChase

system as well as scripted dialogue training for nurses may help reduce the anxiety surrounding the

location tracking of the wheelchairs.

Ultimately, these unexpected and unintended consequences may not be fully realized and

understood until a real-life test could be conducted in an actual hospital. Such a test should include

the capture of user feedback, to ensure that the system is not only working as intended by making

the wheelchair process more efficient, but also not reducing employee or volunteer morale in other

ways. We believe WheelChase is an interesting and technically viable concept with a significant

chance of commercial success. Further research is required, of course, to bring our conceptual

model to a phase ready for commercialization. However, the information and tests presented here

should serve as a starting point for those wishing to explore these ideas in greater detail, and work

to ultimately reduce the cost of healthcare by increasing efficiency.

20

APPENDIX A: MOBILE WEB PROTOTYPE SCREENS

21

22

23

24

25

26

27

28

29

30

31

APPENDIX B: WEB APPLICATION PROTOTYPE SCREENS

32

33

34

35

36

37

38

39