MEDICONNECT

Natan Cohen cohenn@wam.umd.edu -Documentation, Usability Testing, Report - Presentation Of Design

Kinga Dobolyi kinga@cs.umd.edu -Documentation, Usability Testing, Report - Conclusion, Development Process

Kwang Hyun hyunkw@wam.umd.edu -Interface Implementation, Report – Miscellaneous, Abstract

Alexei Ivanov alexei55@hotmail.com -Interface Implementation, Report - Web Page, Paper Editing

Steve Pont srpont@wam.umd.edu -Interface Implementation, Report - Introduction, References

Abstract

MediConnect is a piece of software that allows a user the ability to store and access readings from different medical devices on their personal computer, without having to manually enter these readings. Readings from several different devices, including a scale, thermometer, and blood pressure monitor to name a few, can be uploaded to a computer and these readings can be accessed by date, anywhere from a daily reading all the way to a several-year view. The readings are displayed in both graphical and tabular formats that can be browed in a manner consistent with direct manipulation through a graphical calendar. The software allows the transfer of the records to another party, as well as support for several different user profiles, customizing the number of devices, and printing records.

Top

introduction

Short History of Home-Use Medical Devices

Although there is no commonly available commercial product for home medical use, these types of devices and interfaces do already exist (see Current Devices section below). Hospitals and doctor’s offices have made use of stand-alone “monitor stations” for years. These units are capable of monitoring, displaying, recording, and alerting changes to many different functions. Patients commonly see thermometers and blood pressure sensors in their doctors’ offices. Within the hospital setting, heart-rate monitors are one of the most prominently recognized monitoring devices, but only in rare situations is one seen in the home. Home-use devices tend to be those used for non life-threatening feedback, and this is the area where MediConnect hopes to find a home.

The home-use medical device market has evolved a great deal over the years. Today’s easy-to-use and accurate digital thermometers and scales have replaced the mercury thermometers and spring-driven scales of yesteryear. Technological advances in computers, chemistry and medicine have fostered the creation of many new and exciting home-use health devices. One no longer needs to go to the doctor to have their glucose level checked or heart rate monitored. Many digital devices now exist that make it easy for a person to track these and other health-related data in the privacy of their own home. The next step in the evolution of medical home-test kits is the creation of an elegantly connected group of home-testing devices that can provide users with an overall picture of their health.

Current Home-Use Medical Devices/Interfaces

Home-use medical devices have seen several advancements over the past few years. The ability of individuals to monitor their own glucose levels and the advent of very fast in-ear thermometers are two examples. These new devices provide clear feedback to users, as a result of a great deal of testing and redesign over time. While the actual medical device is certainly important to MediConnect we choose to concentrate on the software interface that will interact with hardware devices similar to those already on the market. We do not aim to re-invent the wheel; it is our goal to integrate the devices that consumers are already comfortable using with a new user-friendly interface. To do this we must first look at some of the current endeavors into this field.

The newest advancements in monitoring have reached beyond the hospitals and doctors offices for only patients in the most dire of circumstances. Cybercare Technologies (http://www.cyber-care.net) provides a number of products that enable patients to track their conditions, and communicate directly with health providers, nurses, pharmacists, etc. Many of this company’s products use videoconferencing, a windows interface, and many different monitoring devices to provide a central point of action for chronically ill patients. Cybercare has gone to great lengths to tailor its interfaces to the patient. Touch screens are used in many products, along with large icons, and online help and educational materials.

Thanks to the improvements in the laptop and handheld device industry, patients are now able to track health statistics while on the road. Cybercare now offers several mobile devices that enable patients to monitor and share health data while away from the home. Wireless communications are now fast enough that users can even utilize streaming video in mobile situations. The devices created by Cybercare give us an excellent picture of the possibilities for home medical care, but they still seem to be lacking in usability for the common user.

Body Tracker software (http://www.linear-software.com) is an excellent application that is currently available on the market. This software enables a user to track their weight, body fat, and tape measurements of muscle groups. All data is entered via keyboard, so a great deal of the interface is taken up by form-fill-in and menu selection. Graphed data gives users an easy to understand picture of their health history. The interface is a standard Windows-based one, which even novice users should be able to learn. This software certainly has an unrealized potential that MediConnect would like to capitalize on.

The idea of entering data via keyboard is one that has existed for some time. Since calipers and scales are central to the management of body fat and weight measurements, why not enable them to directly connect with the software? It is always the goal of usability improvements to make the common case fast. If a user of software such as Body Tracker will be frequently entering data, why not make the data entry as close to transparent as possible?

ePhysician, Personal Diary, and MyHealthChannel.com are three interesting applications used to track user health statistics. These applications have an extra layer of usability in that the user is able to electronically share data with physicians fairly easily. From the examples of these two products, MediConnect will be able to learn what current users of medical monitoring interfaces are looking for in terms of usability.

Research Concerns

In most devices the interfaces are clean, uncluttered, and provide timely data about a patient’s present condition. There is no doubt that a great deal of planning and testing is essential to the creation of the interface. Michael E. Wiklund is a usability engineering consultant who has helped to design some of these interfaces. According to Wiklund, “The success of most medical devices is closely linked to user-interface quality.”(Wiklund 1998)

Wiklund suggests adherence to ten design standards for medical device interfaces. Several of his ideas seem to be key to the design of the MediConnect interface. Screen density should be reduced, so that the user will not be confused by clutter. Our initial vision of the MediConnect interface had a great deal of clutter due to the need to provide users with an application that was rich with features. Careful consideration of relocation of certain functions, and the use of tabs to hide secondary information helped to simplify the interface along these lines. Another suggestion is that this kind of interface “provides navigation cues and options.”(Wiklund 1998) According to Wiklund’s research, users tend to become lost while using many interfaces. We felt that the use of labeled tabs, and pop-up windows would allow users to see where they came from and how to return to previous screens. Reversibility of action was paramount in our minds as we put together a working prototype.

Another major decision about design was the use of language. Wiklund recommends the elimination of all inconsistencies. While this seems like an obvious necessity in any professional package, it was important to be reminded of this fact. Consistency is a very wide-reaching design idea. Language should be similar throughout an interface, colors should match, graphics should be relatable and standard in size, and the layout should be similar to that which users have seen before (Wiklund notes that users understand the Windows interface, which is used as a model by many current designers).

Research suggests that “obtaining home medical equipment carries a great deal of emotional stress.” (Committee on Human Factors, 1996) It may not be readily apparent to many designers that it can be very disheartening when a person learns that they have diabetes and will have to monitor their glucose level for the rest of their life. It is very important that the MediConnect interface is therefore easy to learn, and friendly in appearance. Too many instructions and mechanical language can turn-off and even upset the chronically ill users of a medical device system. This understanding must be tempered with the realization that the goal of MediConnect is to unite the common user—wishing to track their weight—with the lifelong diabetes patient. There is a responsibility to create an interface that is appealing to both users, without minimizing the importance of either.

MediConnect User Profile

The users of MediConnect should not differ from the current users of home-medical testing devices. In general, target users consist of any person who must (for health reasons), would like to (personal goals or curiosity), or is intrigued by the ability to monitor personal health statistics (the avid “gadget” fan). Users may come from any background, but they would have an understanding of why they are recording some specific health information, and what that information means (although the system will be able to provide some baseline feedback). The devices supported within this system may include any of the following: thermometer, scale, body fat monitor, blood pressure monitor, heart-rate monitor, glucose monitor, cholesterol level tester, pulse monitor, breath capacity tester, and many other home-testing devices.

Many different users can use the devices for many different reasons. An individual with a history of weight control problems may wish to keep a record of fluctuations in body fat, weight and cholesterol; a middle-aged woman may need to keep track of her blood-pressure over a period of time; a college student that has mononucleosis wishes to see how his temperature and body weight have been affective over the course of the illness. A mother could even keep track of her children’s height over time.

Novel Design Specifications

The MediConnect system will employ PC-based software that must be very easy to use for the novice computer user. The users must own a computer and should be computer literate enough to perform basic computer tasks: turning the computer on, installing and opening Windows applications (simple instructions provided), and using the mouse and keyboard. The user must also be able to follow directions to connect an IR receiver to a USB port on the computer.

This system will be designed primarily for people with little or no medical background. With this audience in mind, the health-testing hardware must be no harder to operate than the currently available home-testing devices. Under the best circumstances, the hardware should be made easier to operate than currently available hardware. Following simple instructions, the user should understand how to aim an IR port on each device at the one connected to the computer when prompted by software to do so.

Top

Presentation of design

After much debate over the design of the interface, the group agreed on the following interface. This interface is “windows” based and looks a lot like a typical “windows” application. The interface works under the assumption that the user has prior experience with a computer and has familiarity with “computer” related jargon. The user will take their reading using one of the compatible devices, then run and log into the MediConnect interface. Once there he can upload the readings into the MediConnect database and perform related tasks.

The interface consists of 9 screens and does not extend beyond the depth of 3. The transition diagram (See Figure 1) shows the 9 different screens and their respective Figures.

Figure 1: Transition Diagram

The interface details are described in the documentation below.

Documentation

Overview

MediConnect is an interface for a series of specialized medical devices that interface to a personal computer. MediConnect is designed with the user in mind; it is designed to perform the tasks and provide the functions that a user of these medical devices needs. This documentation provides an informative explanation of the functions and features of the program. As the program nears completion, this documentation will extensively cover the remaining features of the program when they are finalized.

The Login Screen

Upon entering the program, all users will encounter the “Login Screen” (See Figure 1). Each user will have a personalized profile and database that is password-protected from other users. To begin using MediConnect, a user must select his/her profile from the pull-down menu as shown. The user then enters their personal password and left-clicks the “Go” button once with their mouse. The “Help” button will bring up a small window explaining how to get started with MediConnect. The user may also choose to exit the program from here by clicking “Exit”. If a user does not have a profile, s/he must select “New User” from the menu.

Figure 2: Login Screen

The default password for all new users is “new” and the user must enter this password to gain access to the program. Users have the option of updating their profile within the program, such as changing a password or their personal information.

If the user enters a correct password he will be taken to the Main Screen (See below), if the password entered in incorrect, the system will allow the user to re-enter the password.

Main Menu Screen

The main screen is where the user will spend most of their time. Upon entering this part of the program, the user will see their individual profile in the top-left corner of the screen. The calendar is located directly beneath the profile and provides most of the functionality of the program. The tabs on the right are labeled for each medical device and several representations of their data are provided beneath its picture. On the bottom left there are three function buttons that the user will use on a frequent basis. The rest of the options are categorized into three pull down menus at the top of the window (See Figure 3).

Figure 3: Main Menu Screen

Menu Screen Pull Down Tabs

The user spends most of their time interacting with the main screen; however it is necessary to perform a few important functions that can be found in the pull down menus. The three menus are File, Tools, and Help. Some of the options in the pull downs are duplicates of the buttons on the main window, so that the user has more than one way to access an option.

-File Tab

Under the “File” tab there is currently a total of four options: Change User, Export To, Import From, and Exit (See Figure 4). The first option is Change User, when selected the user will be taken back to the Login screen, where they can change the user, or just log-out without totally quitting the program. The Export To option, which is not currently implemented, will allow the user to transfer their data to a PDA device or to other “database” applications such as Excel. Similarly, the Import From option will upload the data from a PDA or a file on their hard drive. The Exit option simply exits the program, unlike the Change User option, which just returns the user to the Login screen.

Figure 4: File Tab Options

-Tool Tab

The “Tools” menu provides the remaining functionality for the program in terms of interacting with the data, as well as personal related options. The tab has three options: Transfer Data, Add/Delete Device, and Options (See Figure 5). The Transfer Data option brings up an interface for the user to communicate with the medical devices, this option is also accessible via the Upload button on the Main window. The user may upload data to the program with a few clicks of the mouse. There is an option called Add/Delete Device, which allows the user to select the devices that MediConnect will use. The Options selection brings up a new screen, which contains the Add/Delete Device option as well as several other options. The user can update their profile, add or remove a device, and send their data via e-mail to their doctor.

Figure 5: Tools Tab Options

-Help Tab

The last menu is entitled “Help” and contains all the information the user needs to function in MediConnect (See Figure 6). By selecting the “How To” link, the user can navigate a comprehensive help system that contains explanations of each feature in MediConnect. The “About MediConnect” link brings up the people who designed and developed the program. When the program is complete there will be more options to choose from but the basic interface will remain.

Figure 6: Help Tab Options

Data Representations

On the right side of the main screen is where all the data will be displayed. Upon login into the system, the user will see the recent data for each device. Besides displaying the recent data this section will show data once the user performs search queries. The section consists of tabs, one for each device currently installed. For each device the user sees the image of the device, the date/s that the data in the windows currently spans, and two representations of the data: Table and Graph. The user can get detailed view of either of the data representations by double clicking on the Table or the Graph (SeeFigure 7).

Figure 7: Data Display

When the user double-clicks on either the table or the graph, a larger image of each will be loaded in its own window. From there the user can save the graph or the table to their hard drive or print the graph on their printer (See Figure 8). If the user graphs a contiguous set of dates, the graph will be continuous without any breaking points. However, the user may choose to graph select months, years or days. In this case, it will be necessary for the graph to insert a breaking point between the non-contiguous set of dates.

Figure 8: Detailed Data Screen

The Calendar

The calendar adds direct manipulation to MediConnect. Users can choose their dates simply by pointing and clicking the days, weeks, months or years to display.

-Single Day Selection

The date marked with a small red circle shows the current day. The current month and year are also displayed. To show the readings for today, the user can click “Today” and the results will be displayed in the table and graph. Individual days can be selected by clicking on the dates shown in the calendar display (See Figure 9). The calendar supports multiple selections as well.

Figure 9: Calendar - Single Day

-Multiple Day Selection

Simply click and drag the mouse across the calendar to select multiple days or weeks. Below the calendar the user can find a text display of the current dates selected to be sure that the desired dates are chosen (See Figure 10). Then the user clicks “Show Readings” and the desired data will appear in the tables and graphs.

Figure 10: Calendar - Multiple Days

-Month/Multiple Month

To select an entire month or multiple months, the user can click the “Show Full Month” radio button and then select the desired month/s (See Figure 11).

Figure 11: Calendar - Month Display

-Year/ Multiple Year

The same process can be done to select particular years. Click the “Show Full Year” radio button and then select the desired years to display (See Figure 12).

Figure 12: Calendar - Year Display

The Options Screen

The “Options Screen” provides the user with MediConnect’s three additional functionalities. There is a tab that lets the user update their profile, a tab for adding and removing medical devices and a tab for sending their data via e-mail.

-Update User Profile Tab

The first tab is labeled “Update User Profile” and provides fields for the user to fill in their personal information such as their name, age and gender. The user can change their password via the two fields provided at the bottom; this is required for all new users. The user can optionally include a picture of him or herself or any picture of their choosing (See Figure 13). After filling in the fields and optionally including a picture, the user must click the “Save” button. The user can click “Cancel” to discard all changes at any time.

Figure 13: Options - Update User Profiles

-Add/Remove Device Tab

The second tab is labeled “Add/Remove Device” and serves as a quick interface for the user to control which medical devices are currently connected. To add a device the user clicks on “Add Device” and selects which device to link with MediConnect. Removing devices is easy with the list of devices currently connected. The user can simply click on the device they wish to remove and click “Remove” to confirm their selection (See Figure 14).

Figure 14: Options - Add/Remove Devices

-Send Data Tab

The third feature of the “Options” screen is the ability to send various data to other users of MediConnect. This feature allows users to send data to their doctor or relative. The interface is much like the interface provided for many common e-mail programs. The user types in the name of the recipient in the “To:” field and can send copies to other recipients via the “CC:” field. The user can type an optional message or send an attachment with their data but this is not mandatory. When the user transmits the message, all the data stored in MediConnect is sent along with the message. The user can quickly select the other tabs by clicking on the headings along the top of the menu (See Figure 15).

Figure 15: Options - Send Data

The Device Upload Screen

The final interface of MediConnect provides the ability to upload new data from the medical devices. The user first selects a device from the pull-down menu provided. The entire list of supported medical devices will appear. Future versions of MediConnect will support additional medical devices for use with the program (See Figure 16). The date of the last reading is displayed for convenience to notify the user of the last time they uploaded data from that particular device.

Figure 16: Device Upload Screen

After selecting the medical device the user clicks the “Ready” button. After doing so the button disappears and is replaced by the text in the picture shown (See Figure 8).

Figure 17: Waiting to Upload Message

The program is now ready to receive the data but must wait for the medical device to initiate the transfer. Since there are currently no working models of these medical devices, we have created a temporary screen that shows a picture of the medical device selected with a red transmit button (See Figure 18).

Figure 18: Device Simulator

Simply click the red button shown on the image to create the same effect as pushing the “Transmit” button on a real medical device. After the red button is clicked, the progress bar on the previous screen should now read 100% and the date should be updated. Now the data has been successfully uploaded to MediConnect’s database and is ready for use (See Figure 19).

Figure 19: Upload Success Screen

The user can select the help feature at any time by clicking “Help”. After the data has been retrieved from the medical device the clicks “Close” and is returned to the main screen.

Top

Development Process

In developing our software, it was clear there were three axes to work with: the medical device, the date of the record, and the user.

Anywhere from one to seven (or more) medical devices would have to be supported by our design. Not only would our program have to have the capability to add and delete a device, but there would also need to be a way to efficiently manage the different devices for which software is installed. The most logical way we decided to go about this was to use tabs on the main window for every different device. A template was designed for all devices, and was customized to the different installed components. There were also some functions that were deemed universal, which remained on the left side of the screen and were not part of the tabbed section.

There was initially some difference in the low fidelity prototypes over the organization of the software – whether this should be device-based (as in picture A) or task-based (as in picture B). A device-based approach would have a different screen for each device (with tasks being selected one at a time), while a task-based device would have a different screen for each task (with devices being selected one at a time). Both of these are redundant in some fashion and can be confusing to the user, so in the end we decided to combine the two approaches onto one screen. That way the tasks are always available on one side of the screen, while the devices can be changed on the other side. More importantly, this allows the main screen to be stable, because there is no need to navigate between devices or tasks, as some of the prototypes initially propose, and therefore no need to ever go back to the ‘main menu’.

Picture A: Low-Fidelity 1

Picture B: Low-Fidelity 2

One only resulting issue from adopting the hybrid, one-screen approach was that the main screen would be too small to incorporate any details for readings. To solve this, any function that needed a larger screen, such as a graph view or an upload, would have its own pop-up screen. While this adds some clutter to the use, the sense of ‘home’ in having a stable main menu outweighed the downsides in our opinions. For example, double-clicking on the mini-version of a graph on the main menu results in a new pop-up window, where the detail is clearly visible.

Another advantage with adopting the hybrid, main-menu approach is that in the end the screen was split into a stable environment and a changing environment, upon which all actions are performed. This becomes clear when we examine the handling of the date of the record being accessed, which is the second axis we had to work with. In the end, all functions and tasks the user had to do were ‘stable’ and therefore had some representation on the left, non-changing side of the screen. The right side would then change depending on which device was selected. But it would also update when the date of the record being displayed was modified – if, for example, someone switched from the view of weight on January 1, 2002 to January 3, 2002 – the graph and table on the right side of the screen would automatically be updated.

Deciding on the representation of how to maneuver through different dates in displaying records was the most difficult design problem for our group. It was clear that we should be using direct manipulation as much as possible, since this method of interaction with the computer is what users generally prefer. We wanted user to be able to enter a date on the left side of the screen and have it displayed on the right side. Making our lives a bit more difficult, we decided that the graph and table on the right side of the screen would automatically update while the user browsed different dates.

Our main difficulty however, lay in the depiction of the date itself on the left side of the screen. Having the user enter in text a month, day, and year is not only error-prone, but would not support the weekly, monthly, yearly, and multi-year views we thought would be important. Our ideal was to graphically represent the calendar year, and allow the user to zoom in and out in some form, while the graph and table on the right side of the screen automatically update with each zoom. Therefore, the approach of using radio buttons to select a day, week, month, or year view was abandoned in favor of a graphical calendar.

Several different considerations were made for how to do zooming in the calendar – ideally, we would have liked the user to be able to click on the image to get a closer view, but we were limited in our visual basic knowledge since zooming in was fine, but zooming out was a problem. In the end we had to settle on a month view of the calendar, which would allow the user to click on one or more days and the appropriate graph and table would appear on the right side of the screen. Zooming out was accomplished by being able to scroll through months at the top of the month menu, or by setting the month and/or year through a combo box, all of which was coordinated so that they all showed the same date (changing the month in the combo box would also change it in the graphical display and visa versa). We had considered using two scroll bars on the left and bottom of the graphical calendar to accomplish the viewing though direct manipulation by dragging these bars. The bar on the left would zoom anywhere from 10 years (at the very top), to year, to month, to week, to day, while the bottom bar would move to the next element in sequence (like from January to February or 2001 to 2002). Once in the month view you could still click on the graphical image to get the desired display. In the end our limitation of visual basic knowledge left this path for other people to explore, and we incorporated as much direct manipulation as we could under the time constraints.

The final axis, which our software worked around, was the fact that several different users may be in the same household and want to use this program. Storing the user’s data in separate files and having the user identify him or herself to the program before getting started easily solved this. We decided people would prefer having passwords, and this decision was supported in our usability testing. Also, the users have the option of personalizing their information, such as their target weight, height, age, etc, which also must be stored separately.

Once it became clear that the main screen would be split into a changing part based on the device and date, and a stable set of functions, it was time to decide what functions would be immediately available to the user on the left side of the screen. Showing the readings was the most obvious, and the upload feature was something that we felt would be frequently used enough to warrant space on the main page. But since the upload function is device dependant, we also put it on the right side of the page which changes with each device.

Help and logout were also placed on the stable part of the main page, but in the same way upload is redundant, these functions were also included in the bar at the top of the page. This bar contained all the other functions our software could perform, including transfer of files to a doctor, updating the user information, and so forth. An issue came up around the use of the word logout over exit or quit, since these could be confusing. Since to get to the main page you have to log in as a user, someone might think that ‘quit’ or ‘exit’ might just put them back to the log in page, which would not be the case. Instead, we chose to have logout to indicate that you are signing off as the current user. If this is not intuitive to a person ‘Change User’ is available in the car at the top of the screen under File, much like in America Online’s Instant Messenger program. In the worst case, the user may interpret the logout as the close program, but this puts them back to the log in page, from which there is an Exit button. Exit is also available in the bar at the top of the page. While the term Exit and Help are used consistently throughout the software, we chose to have Logout and Change User with different wording incase it wasn’t clear what logout meant. In retrospect, we might just want to change the Logout button to Change User since this is clearer.

Finally, we had to decide on what other pop-up windows we would have besides the main menu. It was logical to have a log in menu that is the first screen the user sees since access to the records should not be granted without password protection. Here the user has the option of signing in as a new user as well, or an existing user. To be consistent, there are Exit and Help buttons on this first window. Other windows we designed were the user information screen, upload data, and transfer information, all which can be accessed through the bar at the top of the main menu. These menus use form fill-in and combo boxes as appropriate, and provide feedback to the user.

The upload screen for example instructs the user how to upload from the correct device after that device is selected. If this window is accessed through the left side of the screen on the main menu, the user is prompted to select one of the devices from a combo box, but if it is selected from the right side of the screen by double-clicking on the image of the device, the correct device is pre-selected, so there is less work for the user to do. The upload window tells the user to press the red button on the device to upload data, and provides feedback on the progress of the upload through a progress bar. The other three main actions, transfer, update data, and add/remove a device were also handled in pop-up windows. To aid the user in learning what functions the software can perform, these three functions are also represented in the tab button format with a tab for each action respectively. Form fill-in is used to enter most of the data since the fields vary widely and there is little way to have error prevention.

After developing the high fidelity prototype with these thoughts in mind, we conducted usability testing. Five subjects were used in preliminary testing in which we wanted to see if there were any glaring problems that needed to be fixed before we did the real usability tests. As we should have expected, we got rave reviews on the layout and design of our project, since we did not ask them to perform specific tasks, instead just to look at the design and give some opinions on it. The subjects reported liking the layout and the calendar.

Afterwards a set of tasks was developed to test different aspects of our design. Varying degrees of difficulty were tested to get a sense not only of the software, but also of the user. Thirteen tasks were developed:

1. Sign in as an already existing user

2. What is the current user’s target weight

3. Enter today’s weight on the scale and transfer your weight to your doctor

4. Print out a graph of your weight for March 2002

5. Print out a table of your weight for March 2002

6. Print out a graph of your weight for the second week of March 2002

7. Find the year when you weighed the most in the past 5 years (use the 5 year graph to do this)

8. Enter a temperature reading

9. Print out the records for temperature January 5, 2002

10. Print out a graph for your temperature readings for the months of January, February, and March in 2002

11. Change your weight goal to 156 pounds

12. Log on as a new user

13. Quit the program

Tasks 1, 12, and 13 were meant to be very easy and intuitive so that we could get a sense of the user’s overall familiarity with computers – if a subject had difficulty with these tasks, then it would be unlikely they could perform any of the other ones. Tasks 4, 5, 6, 7, 9, and 10 all require the user to use the calendar to access a different record, and then print it out. These were meant to see how easy it was to get a reading for a specific day, week, month, set of months, year, and set of years, which tested all the different levels of zooming with the dates. Tasks 3, 8, and 11 all are designed to test the actions of transfer, upload, and update data respectively, and we expected them to require some intuition. We were careful not to use the same terms on the task list as the words found in our software to test our program (enter versus upload, of example), because it is not guaranteed that the user will think of the actions with the same words as our program uses.

A set of pre and post-session questions were also put together. The pre-session questions were somewhat informal, with the key ones being how many years has the subject been using computers and how familiar they were with the medical devices. The post session questions asked the user to rate the difficulty of each task on a scale of 1 to 5, as well as another set of 1 to 5 ratings of general satisfaction with features that are not related to the tasks (which is more of what the pilot testing accomplished).

Eight subjects were given ten minutes to complete the set of 13 tasks. Most of the subjects were college-aged students at the university of Maryland, with several years of computer experience, and all reported good familiarity with the medical devices. A member of our group was present to observe each session and take notes. The subjects were given a quick background on the nature of our software and reminded that the tests were not judging them, but instead the software. Since the prototype would not show the graphs or tables properly, these were simulated on a web page and the subject was directed to them accordingly and instructed to pretend that they were in the enlarged window that appeared.

The average difficulty of the tasks as found by the tests subjects are summarized in the following table:

Task	Difficulty
1. Sign in as an already existing user	4.875
2. What is the current user’s target weight	3.6
3. Enter today’s weight on the scale and transfer your weight to your doctor	2.875
4. Print out a graph of your weight for March 2002	2.25
5. Print out a table of your weight for March 2002	2.71
6. Print out a graph of your weight for the second week of March 2002	3
7. Find the year when you weighed the most in the past 5 years (use the 5 year graph to do this)	-
8. Enter a temperature reading	3.94
9. Print out the records for temperature January 5, 2002	4
10. Print out a graph for your temperature readings for the months of January, February, and March in 2002	-
11. Change your weight goal to 156 pounds	-
12. Log on as a new user	4.625
13. Quit the program	5

Table 1: Task Difficulty

As expected, most users found tasks 1, 12, and 13 very easy. The printing out tasks, however, did not do well overall because subjects did not know how to find the print button (you need to double-click on the small image in the main menu to get a larger window which has the print option). Many users looked under File for a Print function but few of them double-clicked on the image to get a larger view (and from that point printing was trivial). This suggested to us that either we need to be clearer about what ‘getting details’ means (as these were the instructions provided in the main menu), or provide print as a universal function on the left side of the screen, or have it in the options bar at the top (or some combination of these three solutions). We had expected our users to want to look at a larger image before deciding to print in real life, but the usability test pointed out how this logic could be flawed, and also that our design was grossly incompetent in this respect.

Some users had difficulty with task 3, while some did not. We suspect that this is because some users recognized that enter and upload are the same function, while others did not, although task 8 which was similar did much better – the problem seems to lie in the transfer of the data. Even though ‘transfer’ is the same word as our program uses, subjects had difficulty finding this action in the bar at the top of the screen. Finally, some tasks could not be completed because our software didn’t support those functions yet at the time of usability testing, and those are noted with a dash in the difficulty column of the table.

Overall two things became very clear to the design team; that there needed to be a more obvious way to print the data, and that some way, such as a mini-tutorial for new users upon opening the program, might want to be provided so users have an easier time finding the actions that they want to complete. What was somewhat surprising was how successful the calendar representation was, even though this is what we considered the most difficult part of our design. All the users were able to locate the right reading, even if they were not able to print it out, even with the complicated settings that had to be in place to get a single month display, for example. Obviously, the direct manipulation through the graphical representation of the date was a success and there were no complaints about this part of the testing, which is one of the places where we anticipated a lot of difficulty.

The log in screen was also successful, since this was the first screen the users encountered. On the other hand, when the task required the users to update their data, this was much more difficult to find. What also became obvious was that a new user is not immediately prompted to enter their data as soon as they log into the software; instead they are sent to the main screen. If, instead, there were put in the Update User Profile window, which contains tabs to both transfer and add/remove a device, this would be a way of getting users familiar with the system, and in the worst case if they can figure out how to find one of these three actions, they will be able to get to the other two, even if they cannot get to them directly.

Many users felt uncomfortable or scared to click and try around or try different things when the answer was not apparent. When users were performing some of the more difficult tasks, like entering today’s weight from the scale or printing a graph, some users expressed no apprehension clicking and exploring the menus. Some users felt lost or scared that they would lose the main screen when they could not directly see how to perform a task. In our design we had specifically tried to make the main screen the locus of control; the main screen never disappears; at worst a pop-up window obscures it, but it is always there. One solution is to put more actions into the main screen itself, so that users feel more comfortable – it is clear that is may be needed anyway, since many users had difficulty finding the actions that were not on the main page, and there are only about four of them to include.

Overall the subjects were satisfied with the non task-related aspects of the software, summarized in the following table:

Feature	Rating
Tabs to maneuver through devices	4.25
Colors used	3.875
Size of windows	3.31
Font size	4
Size of buttons	4.5
Bar at top of screen	3.75
Use of passwords for users	4.625
System speed	4.75
Feedback from program	3.57

Table 2: Non Task-Related Ratings

The use of passwords and button size were the most liked by users, while the size of the windows and the feedback from the program is what was disliked, although the overall rating of the system features was above satisfactory. The windows had originally been much larger, but had to be resized to fit onto the screen in the lecture hall. One possible solution is to allow the screen to scroll, although we think that having a small window might be better under some circumstances than a scrolling one, since with scrolling there is the danger that users may forget to scroll and therefore lose some of the functionality. On the other hand, we anticipate that many of the customers will be elderly (which almost none of our subjects were), and therefore it is important for them to be able to clearly see the screen.

Top

Conclusion

The final status of the software was a semi-working refined prototype that simulated all of the actions possible on the computer. Transfer of data between the medical devices and the computer, and the computer and another party were simulated. The user interface for the access of the data readings was completed, even though no actual data was present, besides a few sample data sets (dates and readings) that were given, to allow the user to experience what getting a reading would be like. Obviously, in an actual implementation of the program, an extensive database would have to be designed that would allow for the entry and upkeep of readings. In our project we used graphical images to represent all the graphs and tables of readings, but in an actual implementation these would instead have to be fields that change at the user’s request. This can be somewhat difficult to accomplish for the visual basic novice, since each graph would have to re-size itself depending on the zoom of the reading, as well as being able to display the appropriate reading values. Similarly, databases would have to be maintained for user info, reading dates, and the like – these aspects were only simulated in our software through images.

Additionally, in an actual implantation, the medical devices would have to have to have working radio transmissions that communicate with the computer. On the technical side, there would also have to be working components for the addition of a medical device to the software’s set of devices.

Future developers of the software might want to explore features of the program that we only touched upon. For example, the transfer of the data to a doctor must be done manually. This feature might want to be expanded to allow for automatic transmission to a doctor or hospital on a regular basis. Consequently, both the user and the medical personnel would have to have compatible databases, which would greatly expand the market for these types of devices and systems if a standard could be created. And if a doctor could have access to a user’s data, it would be logical that a user could have access to the data the doctor has on record as well, thereby making their entire medical records available to them on their computer. With this setup in mind, the software could also be set up as more of a home medical advisor, giving progress reports on weight loss for example, which could be expanded into many other types of readings. A built-in medical encyclopedia might be one consideration. Additionally, new features might want to be added that can perform statistical analysis of the readings and provide feedback in this manner beyond the scope of something simple like ‘you are above your target weight’ or ‘you have a fever’. What sort of statistical analysis that might be warranted would be left up to the future developer to research.

Finally, future developers might want to further emphasize the fact that most likely a large number of the users of this software are going to be senior citizens. Consequently, it would be especially important to have easily visible displays with large fonts and graphics. Also, since at this point in time it seems that the older a person is, in general, the less familiar they are with computers, the ease of learning to use the software is of utmost importance in its success. Here the issue of where to put the features that are not currently obvious on the main menu – print, transfer, add a device, and update user data, becomes even more difficult because with larger fonts there is less space to but in buttons for these features, but we suspect that providing buttons for them on the main screen would be the easiest way new users would be able to find them. Future developers might want to conduct additional usability testing, this time with a much more elderly subject base, on two new designs of the software: one with additional buttons in the main menu that allow direct access to the actions that are now ‘hidden’, versus a program that provides a quick how-to tutorial when a person signs on as a new user to show where the hidden functions are available. In reality, as demonstrated by the usability tests, the problem is really that users are apprehensive in exploring the interface – if all of the possible functions could be found at the bar at the top of the main screen, and users were willing to explore in this bar to find what they need, it would be a lot easier for them to gain competence with the system. Taken as a whole, the software as it stands provides an almost complete framework for user interaction with the data being recorded by the devices, minus a few functions, such as the update of personal information, which has not yet been incorporated into the program. Future developments should focus on catering to the target users and making the software compatible with computer based medical records that make the scope of the program in its ability to store and give access to medical records infinite.

Top

Acknowledgements

We would like to thank our professor, Ben Shneiderman, for the continued support and advice for our group, as well as all the participants of our usability testing.

Top

References

Academic Papers

Klatzky, Kober and Mavor; editors, “Safe, Comfortable, Attractive, and Easy to Use: Improving the Usability of Home Medical Devices”, Klatzky, Kober and Mavor, editors; Committee on Human Factors, National Research Council, 1996

http://www.nap.edu/books/NI000021/html/index.html

Wiklund, Michael E., “Making Medical Device Interfaces More User-Friendly”

http://www.devicelink.com/mddi/archive/98/05/032.html

Industrial Reports

Borden, William; “Panasonic Debuts Web-Based Home Health Care Device”, Reuters Limited, 2001.

http://www.etango.com/PR/news_stories/2001-05-31_Panasonic_health_care_device.pdf

Ogden, Frank; “This Thermometer You Swallow”

http://drtomorrow.com/lessons/lessons6/29.html

Symbol Corporation, Press Release; “Shirt-Pocket Device Provides Patient Information”, 1999.

http://www.symbol.com/news/pressreleases/press_releases__portsys__duke_.html

Commercial Products

Body Tracker by Linear Software