Back to Main Index
MedCheck: PDA Application for Patients with Long-Term Health Conditions
that uses LifeLines as a primary means to display medical data
Designed by Team PIC
|
Rishi Gupta |
|
|
Christine Hwang |
|
|
Jane Lin |
|
|
Michael Lin |
May 6, 2004
|
2 |
|
|
2 |
|
|
Introduction |
-- |
|
3 |
|
|
4 |
|
|
Presentation of Design |
-- |
|
6 |
|
|
6 |
|
|
7 |
|
|
10 |
|
|
Development Process |
-- |
|
14 |
|
|
14 |
|
|
17 |
|
|
17 |
|
|
22 |
|
|
Conclusions |
-- |
|
22 |
|
|
22 |
|
|
23 |
|
|
23 |
|
|
24 |
|
|
|
|
|
25 |
|
|
26 |
|
|
28 |
|
|
29 |
Currently, there are limited personal digital assistant (PDA) applications available for patients with long-term health conditions to visually display their medical data. The application presented in this research paper offers one possible solution to this problem. Because of the wide range of long-term health conditions, the research team chose to narrow the focus with a case-study on diabetes patients. Therefore, all of the studies discussed will be focused on this particular group of individuals. In addition, the prototype created was called DiabCheck, as will be seen in the screenshots. This was to create a stronger relationship between the application and the test subjects. The marketable name of the application is MedCheck based on the general purpose. However, PDA Interface Creators (PIC) believes that having more features will be much more beneficial. Therefore, PIC designed and implemented a software prototype that enables users to view their medical history and ongoing medical status, more specifically, their symptoms, diagnoses, treatments, and test results. The software is centered on a timeline visual representation method, “LifeLines.” An important note is that the actual implementation does not build on the previous LifeLines implementation. Rather, it is attempt to add a PDA graphical prototype of the LifeLines concept. LifeLines is a tool that graphically represents data using a series of horizontal bars and lines developed by the Human Computer Interaction Lab at the University of Maryland, College Park.
Rishi Gupta
Co-wrote tasks and requirements, references, task list, usability test report, final paper
Implemented changes to high-fidelity prototype, login screen, and select year function
Designed low – fidelity prototype
Completed presentations
Completed webpage
Administered usability tests
Christine Hwang
Co-Wrote tasks and requirements, references, questionnaires, usability test report, final paper
Designed low – fidelity prototype
Implemented most of high-fidelity prototype
Edited usability test report
Administered usability tests
Jane Lin
Co-Wrote tasks and requirements, references, task list, questionnaires, usability test report, final paper
Compiled, rewrote, and edited all deliverables
Administered usability tests
Michael Lin
Co-Wrote references, usability test report, final paper
Implemented scrolling
Administered usability tests
Keeping a personal medical and health records organized and having immediate access to them have not always been a very easy task. Before computer software existed for such purposes, this task would have to be completed by recording everything down by hand, either on regular, notebook paper or on personal medical history forms. However, these earlier methods were very cumbersome and had many problems. For example, if a person writes something down and realizes at a later time that he/she forgot something, he/she would have to go back and try to “insert” in the addition by writing either in the margins or between the lines. This makes the written document cluttered and hard to refer to later on when there might be a need. Furthermore, with time, the written document will deteriorate, making it impossible to read as well. This is, of course, assuming that the documents will not be misplaced or thrown out accidentally.
Today, much computer software is specifically developed to serve such a purpose. The aim of these applications is to help people keep track of their own medical history in an organized, manageable, and easily accessible fashion. For example, typed-up documents are not only much easier to read than hand-written notes, but they also last longer. Inserting and deleting parts to the document is much easier with computer applications because everything will adjust with the new addition. Having all personal medical and health records on a home computer will make it hard for someone to lose or misplace records as well.
However, one major drawback with having everything located on a home computer is loss of “record mobility.” In other words, it is extremely difficult (rather almost impossible) for someone to show their doctor’s or medical advisors something they recorded on their own computer, say during an appointment. Even though a laptop makes it slightly easier to carry personal medical and health records to appointments or anywhere else, it is still quite inconvenient because of its size and weight. Laptops are also much more expensive than desktop computers, so this option is not very suitable to the general public.
With the advent of the Personal Digital Assistant [PDA], new possibilities for software applications arose. PDAs are small and light enough to be carried around (as many people do) and have sufficient functions needed to record personal medical and health records. PDAs are also not as expensive as laptops and more affordable. Using a PDA will allow the user to record and see any medical information at any time and any place. Records can be stored either on the PDA itself or be transferred to a computer when space runs out on the PDA.
Besides finding the best ways to store personal medical and health records, another major issue is finding the best ways to display the records in a coherent and intuitive manner. The goal of the display should be to allow interpreters to easily identify the information captured in the record in the shortest amount of time. Having stored text offers a way to record thoughts and observations. However, reviewing past records in this format is extremely difficult because reading through the text is the only way to see what that record was about. Thus, visual representations of medical records have increasing interest and is preferred by interpreters.
Specifically, the use of LifeLines is an appealing means of graphically displaying medical data across a period of time. Associated with a timeline, each LifeLine – a horizontal bar or line – represents an event for a certain time period; a bar represents a longer span while a line represents a shorter span. There can also be multiple LifeLines or events for each category by placing each LifeLine next to or under other LifeLines.
CapMed has developed an innovative method of transporting vital medical records and information from a person’s home to their doctor or hospital. CapMed’s Personal HealthKey™ is a portable USB device small enough to be carried on a keychain. Their USB device is designed to interact with their health record application. It is designed to store a large amount of medical information and be mobile enough to be carried to any medical office with ease. CapMed’s Personal Health Record™ application is designed for personal computer and serves as a very complete way of collecting personal medical records. Demos of their application can be found on their website <http://www.capmed.com/> (CapMed).
The FreeStyle Tracker™ Diabetes Management System developed by Therasense is a good product for tracking blood sugar levels, insulin levels, and meal details for a patient on a handheld PDA. It keeps detailed information from the three categories and allows users to represent the data in line graphs, pie charts, or model day charts. This product does not allow the linking of other medication or treatments that might be associated with a diabetic condition. Also, this product only allows information to be displayed for up to two weeks. The FreeStyle Tracker™ Diabetes Management System can be found at <http://www.therasense.com/tracker/interactive/index.asp> (FreeStyle Tracker).
GlucoTools™ is a set of tools for the Palm Pilot and HandSpring Visor type PDAs that assist diabetics using insulin pumps with managing diabetes. It does not offer a visual representation of the information collected. The PDA screen has no color, but instead, it is displayed as black and white (with some gray). GlucoTools™ is available at <http://glucotools.sourceforge.net> (GlucoTools).
DiaTrends is a computer application that allows tracking of medical data and conditions. It covers a broad range of information like medications or office visits to name a couple. Unlike the previous two products mentioned, DiaTrends is not designed for a PDA (which allows it to have a bigger range of functionality and features). DiaTrends allows graphing of certain collected data as well. DiaTrends is a good product to look at because it starts out with a lot of features. It is much easier to remove features than to think or new ones that would be beneficial to users. DiaTrend can be found at <http://overlooksoftware.com/index.htm> (Overlook Software).
The Human-Computer Interaction Lab [HCIL] at the University of Maryland, College Park researched and developed a unique medical record visualization technique in their project “LifeLines.” The visualization technique has a “one screen overview of the record using timelines [to provide] direct access to the data….patient records, medical problems, hospitalization and medications can be represented as horizontal lines, while icons represent discrete events such as physician consultations, progress notes or tests. Line color and thickness can illustrate relationships or significance. Rescaling tools and filters allow users to focus on part of the information, revealing more details” (Human-Computer). Since the HCIL project intended for LifeLines to be used on computers, much more functionality is incorporated into the model than if, say, a PDA was used instead. As noted on the HCIL webpage, having this timeline view of records can 1) reduce the chances of missing information, 2) facilitate the spotting of anomalies and trends 3) streamline the access to details (as LifeLines act as large menus) and 4) remain simple and tailorable to various applications (Human-Computer). LifeLines is intended to be used on a computer so that all the data can be displayed at once for easier comparisons and observations. Dina Demner, a participant in the development of LifeLines-2, further states that “LifeLines was designed as an answer to specific users’ need to summarize personally history in a single screen” (Demner).
Many other commercial products that offer ways to manage and display diabetic-related information exist. However, the scope of functionalities they offer and the different visualization methods allowed are pretty much the same and do not have much difference.
PDA Interface Creators [PIC] is proposing a way of tracking general medical data using the LifeLines visualization method to give users a new way of interpreting and understanding the data. The proposed application will be modeled through a Windows CE Pocket PC Emulator offered in Visual Basics .NET. As stated in the abstract, PIC will only be doing a case-study on diabetes patients in this report.
Presentation of Design: Overview of Approach and Solution
PIC designed the application to specifically address the users’ needs. In particular, it was important to consider what type of information was necessary and how the application would be utilized. Thus throughout the entire process, the group employed a customer-centric approach. Initially, the team defined the system requirements based on the users’ tasks before developing the low-fidelity prototypes based on these needs. PIC sought feedback on the pros and cons for each of the prototypes and then considered those comments when developing the high-fidelity prototype. Upon completion of the high-fidelity prototype, a usability test was conducted where eight users were asked to test the prototype and to provide suggestions for improvements.
All these steps enabled the team to develop a unique and easy-to-follow user interface that offers the necessary functionality for the user. Specifically, PIC used a graphical representation tool to capture and represent the data in an easy to understand view for four categories - symptoms, diagnoses, treatments, and test results. The team then supplemented the tool with additional screens to provide more detailed information. The group also provided alternative views of the data depending on what information the user wanted to see. For instance, if the user wanted to view all related data across the four categories, then the user could see a screen of only those events that were connected.
Presentation of Design: Transition Diagram of Design
Presentation of
Design: Screen Shots of Final Design
(Note: The following screenshots show the
application with the name as DiabCheck. However, the final marketable application name
will be MedCheck.)
Figure 2: Login Screen: Allows the user to Figure 3: Main LifeLines Screen: Displays the
enter in their username and password LifeLines across all 4 categories.
to login. There is also a button with the When a lifeline is tapped and held,
paramedic symbol on it to quickly via a submenu appears giving the user
the user’s profile. The option to view Related Events
or Details about the lifeline.
Figure 4: Main LifeLines Screen with Select Year Figure 5: Related Events Screen: Displays all
Box: Same as the other LifeLines screen events that are related to each other.
with the addition of the ability to jump to This screen is reached by choosing
a year. Related Events under the lifeline
submenu.
Figure 6: Test Results Details Screen: Displays Figure 7: Symptom Details Screen: Displays
the results of a test result lifeline. This the results of a symptom lifeline.
screen is reached by choosing Details This is reached by choosing Details
under the lifeline submenu. under the lifeline submenu.
Figure 8: Treatment Details Screen: Displays Figure 9: General Help Screen: Displays
the results of a treatment lifeline. This general help for the application.
screen is reached by choosing Details
under the lifeline submenu.
Figure 10: Expanded Category Screen: Displays Figure 11: Search Screen: This screen is used to
one category in the whole screen so the search for any keyword, usually
user can get a more complete and clear associated with an event. A specific
view of the category selected. This Category can be chosen, and the
screen is reached by tapping and holding dates between which should be
on the category label in the main LifeLines searched must be entered.
screen.
Figure 12: Profile Screen: Displays brief, important
health information about the user. This screen
can be reached from the Login Screen as well
as any other screen from the Main Menu.
Presentation of Design: Tutorial/Help
Welcome to the MedCheck PDA application. This application will assist you in viewing and tracking your personal health events using a “LifeLines” representation. Each lifeline is associated with a health event, whether it be a specific diagnosis, symptom, treatment, or test result. These events are viewed in a time continuum so relationships can be drawn if need be.
Login Screen:
* Username: Your username, enter it in via a text entering device.
* Password: Your password associated with the username.
Login Button: Tap this button when both the username and password have been entered
Paramedic/Profile button: In the situation only general health information is needed about the user, this can be tapped and held to reach a summary screen.
* for the prototype, username is "Bort Simpson", password is "test" It is case-sensitive.
Functions of the application:
After logging in, all of the categories and as many LifeLines as possible are shown on the screen. If there are extra LifeLines for a specific category that cannot fit on the screen, vertical scroll bars on the right-hand side of the categories can be used to scroll through the LifeLines in that specific category. A four month time frame is displayed in the windows at all times. The current time frame can be seen at the top of the screen.
Category Expansion: Categories may be expanded so the LifeLines can be more clearly viewed by tapping on the category label. Below is an example where the “Symptoms” category is expanded:
Figure 13: Main LifeLines Screen Figure 14. Expanded Category Screen.
Related Events: To view other events across categories that are related to a lifeline, the lifeline may be tapped and held and “Related Events” must be chosen. This will remove all unrelated LifeLines and only display related ones. Below is an example:
Figure 15. Main LifeLines Screen with Options. Figure 16. Related Events Screen.
Details: Details of a certain lifeline can be viewed by tapping and holding on the lifeline and then selecting “Details.” This can be done from any LifeLines screen. Below is an example:
Figure 17. Related Events Screen. Figure 18. Detailed Information Screen.
Profile: The profile can be reached via the Login screen and via the main menu from any screen. Examples of both are below:
From the Login screen:
Figure 19. Login Screen. Figure 20. Profile Screen.
From Main Menu:
Figure 21. Expanded Category Screen with Figure 22. Profile Screen.
menu expanded.
Search: This application allows you to search for a keyword in the application based on category and dates you chose to search between. The search screen can be reached from the main menu on any screen as shown below:
Figure 23. Main LifeLines Screen with menu Figure 24. Search Screen.
expanded.
Select a Year: The user can jump to any year a LifeLines screen by choosing the Select Year option in the main menu.
Back: The user can return to the previous screen from any screen in the application by choosing the Back option in the main menu.
Exit: The application can be exited from any screen by choosing the Exit option in the main menu.
Development Process: First Steps
Building from the idea of using PDA’s to display personal medical and health records in a visually appealing and intuitive manner, the first step for PIC was to research existing applications to gain a better understanding of the different type of products available for the various target groups. Based on this research, PIC defined the target user group, their work context, and their needs to develop a list of tasks. Once the expected tasks were completed, the team determined the system requirements – hardware, software, networking, and content – and the desired functionality. Existing products were then researched to determine a benchmark for the interface design and product features. The next step was developing two low-fidelity prototypes, taking into consideration design aspects and features from the benchmarks, that satisfied the specified requirements.
Development Process: Low-Fidelity Prototype
In developing the low-fidelity prototypes, many issues had to be considered. For example, the layout of each screen and the position of icons and/or text, the order in which the information and different screens will be presented to the users, the colors of everything displayed on the screen, and when to use icons instead of text were just some of the things that needed consideration. After examining the different prototypes developed individually, PIC combined good ideas from each of the individual prototypes into two final low-fidelity prototypes.
Below are screen shots from low-fidelity prototype #1:
Figure 25: Welcome screen. “LifeLines” is Figure 26: LifeLines screen – Diagnosis.
used to login. The cross is to view emergency LifeLines represent different diagnosis.
information. The question mark is for help. Colors represent related items across the
four categories [Diagnosis, Treatments,
Symptoms, Test Results].
Figure 27: LifeLines screen – Treatments. Figure 28: LifeLines screen – Symptoms.
Figure 29: LifeLines screen - Test Results.
Below are screen shots from low-fidelity prototype #2.
Figure 30: LifeLines screen. All four categories Figure 31: LifeLines screen. LifeLines can be
are shown on one screen. Vertical scrolling and grouped so that all unrelated LifeLines will
horizontal scrolling exist. disappear making related LifeLines stand out.
Figure 32: LifeLines screen. Detailed information
about a specific lifeline can be seen here.
Both of these prototype designs were then tested by with two subjects to determine what was missing or what needed to be improved. Specific task-centered walkthroughs helped pinpoint very specific design problems as well as what worked well. Although users who performed these walkthroughs were not from the target audience of diabetes patients, they will still be able to provide constructive feedback on the prototype designs. In particular, most of the feedback received related to usability issues and the visual images of the screens.
The most common problem with the designs was that it was hard for the user to find what he/she wanted to do because of the limited screen space PDAs have. For example, some of the information displayed was too cluttered, making it hard to locate something specific. Also, they suggested that the font be slightly increased because it was hard to read. They also stated that the team should improve the order of screens to produce a better flow for the user. Lastly, one of the subjects indicated that the colors used in prototype two were “too girly.”
Positive comments received about the prototypes include creativity and how the information was displayed and grouped. Users also liked how there was a lot of color involved on the different screens and how information was grouped according to the colors.
Development Process: High-Fidelity Prototype
After reviewing comments received from the low-fidelity prototypes, PIC made some changes and implemented additional features to the high-fidelity prototype. PIC combined the best features of both low-fidelity prototypes as a basis for the high-fidelity prototype.
The basic layout of the high-fidelity prototype is taken from low-fidelity prototype #2 because the LifeLines across the four categories [Diagnosis, Treatments, Symptoms, Test Results] are easier to interpret and connect if they are shown on the same screen. Since the main purpose of using LifeLines is so that trends and connections can be easily observed and low-prototype #1 did not offer this way of viewing the LifeLines, PIC ultimately choose prototype #2 as a start. Based on the subjects’comments on the colors of the four categories not being gender neutral, PIC reconsidered the colors used in the high-fidelity prototype to reduce gender bias. For the welcome screen, PIC added a login with a password to provide confidentiality to the patient’s medical records. PIC also replaced the red cross with a traditional blue paramedic symbol to make its function more obvious to emergency personnel. An “Actions” menu button was added to the screens as well to provide more options in an orderly manner to the user. At the bottom of the screen, PIC also added general information – date and type – about each lifeline selected.
Development Process: Usability Testing Process – Subjects and Tasks
PIC divided potential users who might have the need to interact with the MedCheck into two main categories: patients and emergency medical technicians. The diabetic patient is the primary subject as they are going to be the primary user who uses the application to view their personal medical history. They may interact with the application whenever they need detailed information regarding their diagnosis, symptoms, test results, or treatments across a certain time period. EMTs are secondary users because they will only use this application under special and not as frequent circumstances. EMTs will use this application during an emergency situation if the patient is unable to provide their own emergency medical information (i.e. if they are unconscious). Because of the range of user experience with the application, this application must be adaptable to both experienced users (the patients) and inexperienced users (EMTs).
Since the majority of ideal users are diabetic patients, PIC surveyed and identified four diabetic patients. Two emergency medical technicians were also included as test subjects since EMTs are part of the user group. In addition, two other subjects -- frequent PDA users -- were asked to participate in this study because of their experiences and knowledge with PDA interfaces. Two of the diabetic patients have had diabetes for over ten years, and the other two were diagnosed within the last five years. Two of the patients have had emergency situations related to their diabetic condition. Three of the four diabetic patients felt prior to the test that it would be useful to have a visual representation of their diabetes-related information. The pre-screening survey (refer to Appendix A) was distributed to a total of five diabetic patients; four of the patients felt a visual representation of their medical information on their handheld could come in use. This finding is very important because it shows a general interest in the product that PIC is developing.
Tasks for the usability tests are included in Appendix B. Since there are two main targeted audience groups – diabetic patients and emergency medical technicians – the task list is also broken down into two separate lists. A brief explanation of the purpose of MedCheck and how to view the display was given to each subject before their usability test. One team member would sit next to the subject as they completed the task to note down observations and to answer questions subjects might have.
The subjects were found through friends, family members, and peers of members of the team. PIC tried to find test subjects who accurately represent the actual user population. One deviation, however, was the age group of the test subjects – it tended to be younger than the target audience. This trend was the result of convenience and availability of test subjects. This may slightly bias PIC’s test findings because the younger generation tends to be more tech-savvy and familiar with a wider scope of user interfaces than the older generation.
After the subjects completed the usability test, they were asked to fill out a post-test questionnaire that asked them specifics about the tasks they had to complete – how easy were certain tasks, how easy was it to interpret the data shown, etc. Appendix C has the post-test questionnaires for both the EMTs and for the diabetic subjects. For specific reports and summaries on the individual subjects, please refer to Appendix D.
Development Process: Usability Testing Process – Results and Problems
Most of the usability tests were performed in a computer lab on computers with 17” flat panel displays. The test ran for approximately thirty minutes for each of the participants. The subject was first given the pre-screening survey to get a general understanding of their background, medical history related to diabetes, and views towards having a visual representation of their medical information. After the patient’s pre-screening survey was reviewed and the patient was determined as being a “good candidate,” he/she was formally asked to participate in the usability test. Of the thirteen people surveyed, eleven people qualified and eight were able to participate in the usability test. The two factors that automatically disqualified potential subjects during the pre-screening round were 1) subject did not know what diabetes is or 2) subject did not know how to use a personal digital assistant (PDA).
The emergency medical technicians and one frequent PDA user were only responsible for interacting with a very small portion of the application. Because of this, they had a fast learning curve; after performing the usability-tasks once, they were able to repeat the same task easily with less errors and faster time. The main issue these subjects had was knowing to click on the paramedic symbol.
The diabetic subjects and one frequent PDA user understood the software better from a conceptual standpoint than compared to the previous group of subjects, but their tasks were more difficult to accomplish and master. This is mainly due to the extra intricacy involved in their tasks. Furthermore, when selecting specific LifeLines, a slight mis-point with the stylus would cause the wrong lifeline to be selected resulting in the subject getting slightly frustrated. In addition, all of the users had difficulty finding the “Details” and “Related Events” menu. However, once they were told to “tap-and-hold” the lifeline, none of them had difficulty finishing the tasks.
In the post-test questionnaire, the main concerns identified from all the subjects
were that it was the first time they had ever seen this type of
application. In other words, they were not familiar with the intent of
the application and what the types of functions were available. In
general, subjects were very excited about the application and liked the
idea. They noted the representation of data was in an interesting, clear,
and manageable format, but they also recognized that it would take some level
of interaction with the system in order to become familiar with the interface.
Although the overriding concern of all users was the limited viewing
capabilities of a personal digital assistant, they did not have any suggestions
for this problem.
With the completion of the usability tests from both emergency medical technicians (EMTs) and diabetic test subjects, numerous problems with the high-fidelity prototype were identified and brought to the attention of PIC. Similar to problems identified with the two-low fidelity prototypes, most of the feedback received from specific task-centered usability tests using the high-fidelity prototype also related to navigational issues and visualizations of the data shown in the screens.
The table below summarizes the problems that were identified in terms of importance and length of time required to correct the problem. Both of these qualities are measured with a 1-5 scaling where 5 is most important or required a lot of time for completion and 1 is least important or required little time for completion.
|
|
Problems |
Importance |
Effort |
|
1. |
Locating a specific lifeline |
5 |
1 |
|
2. |
Locating emergency medical information |
3 |
4 |
|
3. |
Locating detailed information about medications |
5 |
2 |
|
4. |
Using MedCheck to fill out medical history form |
4 |
4 |
|
5. |
Clicking/selecting a specific lifeline |
5 |
4 |
|
6. |
Displaying only related items on the screen |
4 |
2 |
Table 1. Problems that were encountered by the test subjects
Problem 1: Locating a specific lifeline.
When the users had to find specific LifeLines, they knew under which category it was located. However, within the category, they had to click on each of the LifeLines and look at the description on the bottom to see if that lifeline was the one they were looking for (see Figures 3 or 15 in Presentation of Design). While this was not an issue for most of the test subjects, it could potentially hinder users attempting to find a specific lifeline over a large span of time. A possible solution to this problem would be to implement a search function where the user could type in a keyword, date, or time frame and then a screen would appear with the results.
Problem 2: Locating emergency medical information (i.e. current medications used, current health condition).
Initially, for one of the user tests (subject 3), the only way to access the emergency medical profile was through the main page where a “Paramedic” icon existed in the bottom left-hand corner of the screen (see Figure 2 in Presentation of Design). Thus, when the user was asked to locate the emergency information, he did not have a fast and easy way if he was already logged into the application. Instead, the subject had to click on the menu bar to logout before they can get to the emergency medical information. To resolve this issue, PIC added an option, for the remaining diabetic user tests, of being able to view the owner’s profile on the menu bar on every single screen so that immediate access is available to users. This issue was only a problem for the diabetic test subject because he would actually log into the application, whereas emergency medical technicians only had access to the login screen where the emergency information is readily available.
Problem 3: Locating detailed information
If users did not remember results from previous tests or forgot the side-effects of old medications, they need a fast and easy way to look up the details. Thus, one of the tasks for the diabetic test subjects was to locate the side-effects of a specific medication taken in a specific time period and report how difficult this task was. Because only two taps (click on the specific lifeline, click on the “Details” option that pops up) were required to obtain the information desired, the amount of time it takes to accomplish such a task is not significant. However, because the instructions informing the user of how to go about accomplishing this task is not readily available, all users had a hard time figuring out how to get to the detailed medication screen. This can easily be resolved by adding information on how to do this in the help screen because that is where most of the users will try to look.
Problem 4: Using MedCheck to fill out medical history form.
Because specific information is needed on some medical history forms, PIC asked diabetic test subjects to list current medications the patient was taking and treatments the patient took during 8/97 and 10/97. While the first item was easy to locate for most people since they were listed under the “Profile” screen, the last item was not very easy to do. Since the display of MedCheck only shows LifeLines from the four different categories (test results, treatments, diagnosis, symptoms) and no listing, the test subjects had to manually click on each lifeline under “Treatments” in order to get the description of that treatment for the two month time frame. Furthermore, some of the test subjects did not realize that current medications were listed under “Profile” (see Figure 12 in Presentation of Design) so they were using a similar approach for treatments by clicking each individual lifeline under “Treatments” to locate information about current medications. This latter approach was somewhat time-consuming for users. However, with more practice and use of the application, users will easily learn to look under “Profile” for a list of current medications. Although locating information for previous treatments for two months was potentially redundant for users, the only other potential option would be to provide a search function based on category and time frame. However, there would be minimal benefit since the users have the ability to easily find the two specified months by choosing the year and scrolling to the time frame and then just looking at each of the LifeLines underneath.
Problem 5: Clicking/selecting a specific lifeline.
Because the PDA screen size is limited, all the LifeLines are positioned close to each other. This presents a problem in clicking or selecting a specific lifeline because test subjects occasionally selected a lifeline they had not intended to. To resolve this issue, PIC added another function that allows users to expand a specific category if that category name is selected. For example, when the user taps on “Symptom” in Figure 3 in Presentation of Design, he/she is given the option to expand this category so that more LifeLines in that category can be displayed further apart as shown in Figure 10 in Presentation of Design.
Problem 6: Displaying only related items on the screen.
Although the actual steps to display related items are not difficult, it may present as a problem to new users who are unfamiliar with the application. This problem is similar to problem 3 and can be resolved by adding information in the help screen on how to group related items.
From the problems identified and suggestions made by test
subjects, PIC further refined MedCheck to include additional features (such as
the help screens for the main part of the application). From the feedback
received from the subjects, PIC feels that there could be a market for MedCheck
in the near future. Most of the subjects liked the idea of viewing health
records through LifeLines because it shows much more connection between
differing categories than if each category were to be viewed individually.
Design Process: Post – Usability Test
Based on the comments provided by users, the professors, and classmates, a number of changes were made to the high-fidelity prototype:
1) Profile button in the Main Menu - One of the first changes made early on during the usability tests was adding the profile button to the main menu so that diabetes users did not have to log out to access the profile screen.
2) Accentuating the paramedic icon – The EMTs mentioned that it was not clear that the paramedic picture on the main login could be pressed, so the image was changed to a button image.
3) Help screen – All users with diabetes had difficulty finding the related events and details submenu to click to the appropriate screen, so information was included in the help screen to inform them of how to get to the submenu. Information was also included about the various items in the main menu and their respective functions.
4) Search screen – One of the users indicated that it was difficult to find a specific lifeline and details about a specific event without clicking on every lifeline. Therefore, PIC designed a search screen that would enable users to search for specific items based on keyword, category, and/or time frame.
5) Expanded screen - A user stated that it was hard to tap on a specific lifeline since the LifeLines were small when they appeared on the PDA screen. Therefore, PIC implemented an expanded screen option that enables a user to expand a category. On this screen, the LifeLines are then enlarged so it is easier for users to tap on the lifeline.
Conclusions: Final Status of Implementation
The project currently has the following functionality:
1) Paramedic Support – Paramedics have the ability access the user’s medical profile
2) Privacy Protection – The application is only accessible to users with the correct username and password
3) Graphical Representation of Medical Data – Users have the ability to view the medical data via LifeLines
a. Complete LifeLines View – Users can view all the LifeLines in all four categories [Diagnosis, Treatments, Symptoms, Test Results] within a 6 month time frame
b. Expanded View – Users have the ability to view an expanded screen of a specific category from the Complete LifeLines View or Related LifeLines View.
c. Related LifeLines View – Users have the ability to view only related LifeLines across all four categories from the Complete LifeLines View or Expanded View
4) Detailed Information – Users have the ability to view specific information about a LifeLine from any view
5) Search Ability – Users can see how a search would be performed by:
a. Keyword – Users can specify a keyword
b. Date Range – Users can specify a date range
c. Category – Users can specify a specific category
6) Maneuverability – Users have control to switch screens
a. Time – Users have the ability to switch to a different year in any view
b. Navigation – Users have the ability to go back to the previous screen, their profile, the help screen, and the search screen from any view
7) Help – Users have the ability to access information about the menu options
When developing the PDA application for LifeLines, the team
referenced an existing LifeLines prototype designed for a desktop located on
the University of Maryland's LifeLines webpage. However, because of the innate
differences and unique constraints with PDAs, there are significant differences
between the online version and the version we implemented, as listed below:
- Added EMT feature
- Added Profile screen
- Added Login screen to provide protection
- Added related coloring across categories
- Expanding category expands to full screen and actual
LifeLines expand
- Consistency across Detail screens
- Added pictures to Detailed screens
- Aesthetics improved
- Provided more options to use PDA functionality such as
tap-and-hold to evoke a submenu
- Expanded search ability feature to include data rage and
category
- Removed event name from LifeLines screen because of
clutter and displayed it at the bottom of the screen when a specific lifeline
is tapped
Conclusions: Future Work Possibilities
While PIC addressed many of the tasks brought to the team’s attention,
there still remains potential future work for MedCheck:
1) Incorporation of other categories – The application could be expanded by incorporating other categories besides the four [Diagnosis, Treatments, Symptoms, Test Results] included.
2) Improved help screen - The help screen on the application should include more detailed information depending on which screen the user is on and what function is user is trying to perform.
3) Input data functionality - A way to input data into the application on the PDA has not yet been developed. This is a very important aspect that needs serious consideration since the application cannot be solely used on a PDA without a means for inputting data.
4) Modification of data functionality – Along the same lines as incorporating input data functionality, the user needs a means to modify the data on the PDA once it is inputted.
5) Implementing a synchronization method - Setting up a synchronization method between the PDA and a personal computer will allow much more data manipulation and use of consistent data on both mediums.
6) Search functionality – Although the design for the search interface is complete, the search has not been implemented. There is also no means for the user to view the results. A search function is important for users to be able to find specific events.
7) Dynamic lifelines - Currently, the application is just a interface design, so it does not allow any dynamic lifelines displays. However, for this to be useable, it must be based on some database with actual data to reflect the changes that the user inputs into the application.
Conclusions: Recommendation to Future Lifeline on PDA Developers
There are a few things that must be considered if this product were to be developed again. One of the key considerations is whether or not a PDA is the best device to perform the purposes of the application. There are other mobile devices, for example laptops, that offer much more screen real-estate, which is every bit worth it in this type of implementation and use.
Another important consideration is whether the application should be written for the Palm operating system or for the Pocket PC operating system. Each operating system operates differently with regards to the event and event handling. This choice will have a bigger effect on what language is chosen for implementation. For this project, PIC used the Visual Studios .NET 2003 Mobile edition of Visual Basics to create the prototypes. However, as familiarity with the application arose through extensive use during implementation, PIC realized many limitations of the software. For example, the pocket pc emulator in Visual Studios .NET is not compatible with the Palm OS, which ultimately limits production to both PDA operating systems. In addition, languages such as Java allow for more fine-tuning of the application with regards to dynamic data handling and graphic designs than the mobile version of Visual Basics. Before choosing which programming language will be used, it is very important that it is compatible with the backend database that will be used. The prototype created by PIC does not support dynamic data handling, so this was not a consideration for this project.
The ability to support multiple users must also be heavily considered since PDAs are generally personal devices that are not shared between different people. PIC added the capability to enter in a username and password for confidentiality concerns and, perhaps, multiple logins. However, if it is later decided that only one user should be supported by the application, then a password field alone will be sufficient in the welcome screen.
Acknowledgements
PIC would like to thank Dr. Shneiderman for presenting the opportunity to research,
design, and implement a home medical device to help people track and view their
health conditions. Without the class project assignment, MedCheck would
never have existed. PIC would also like to thank CapMed for the original
idea of displaying health records on a PDA, and Dr. Shneiderman and Dina Demner
for introducing the team to the idea of displaying health records through
LifeLines. These two ideas combined to form foundation and basic idea
that supports MedCheck. Finally, PIC would like to thank all the subjects
who contributed their time to do the preliminary walk-through of the
low-fidelity prototypes, usability tests of the high-fidelity, and
questionnaires that gave the team feedback, suggestions, and problems.
American Diabetes Association. http://www.diabetes.org/home.jsp. Last access on March 3, 2004.
Cap-Med. http://www.capmed.com/. Last access on April 28, 2004.
Demner-Fushman, D., Karagol-Ayan, Burcu. LifeLines-2. Retrieved February, 21, 2003 from Dina Demner.
FreeStyle Tracker Diabetes Management System. Therasense. 3 Mar. 2004. http://www.therasense.com/tracker/product/index.asp. Last access on April 29, 2004.
GlucoTools: Tools for Insulin Pumpers. http://glucotools.sourceforge.net. Last access on April 29, 2004.
Greenwood S., Nealon J. and Marshall P. Agent-Based User Interface Adaptivity in a Medical Decision Support System. http://www.eu-lat.org/eHealth/Greenwood-et-al.pdf. Last access on March 3, 2004.
Human-Computer Interaction Lab / University of Maryland, College Park. http://www.cs.umd.edu/hcil/LifeLines/. Last access on April 28, 2004.
Lindwarm D., Rose, A., Plaisant, C., Norman, K.. Viewing personal history records: A comparison of tabular format and graphical presentation using LifeLines CS-TR-3795, UMIACS-TR-97-45. Revised version appeared in Behavior and Information Technology, 17, 5, 1998, 249-262, May 1997.
Overlook Software: DiaTrends. http://overlooksoftware.com/index.htm. Last access on April 28, 2004.
Plaisant, C., Shneiderman, B., Mushlin, R. An Information Architecture to Support the Visualization of Personal Histories. CS-TR-3855, UMIACS-TR-97-87. Revised version appeared in Information Management and Processing, 34, 5, pp. 581-597, 1998.
Plaisant, P.,
Rose, A. Exploring LifeLines to Visualize Patient Records. A short version of this
report appeared as a poster summary in 1996 American Medical Informatic
Association Annual Fall Symposium (Washington, DC, Oct. 26-30, 1996), pp. 884,
AMIA, Bethesda MD. HCIL-96-04 , CS-TR-3620 , CAR-TR-819, March 1996.
Appendix A. Pre-Screening Survey
Diabetes Look: Pre-Screening Survey
General:
1.
2. Do you own a Personal Digital Assistant (PDA)? □ Yes □ No
3. If yes, does it run the Windows Pocket PC software? □ Yes □ No
Diabetes related questions:
1. What year were you diagnosed with diabetes? 19___
2. Have you had any emergency situations caused from diabetes? □ Yes □ No
If yes, was it:
a. Potentially fatal? □ Yes □ No
b. Involved going to a hospital or clinic? □ Yes □ No
c. Involved assistance from:
Emergency
Medical Technicians?
□ Yes □ No
Bystanders?
□ Yes □ No
Loved ones? □ Yes □ No
d. Do you feel it would have helped if your health
information was available to others around you
at the time? □ Yes □ No
Doctor’s Visits:
1. How often do you go to the doctor’s office?
____ times per: □ Year □ Week
□ Month □ Day
2. Are there times when you need to know your medical history? □ Yes □ No
3. Would you find it helpful if you had a visual representation
of your medical history with you on your PDA? □ Yes □ No
Optional:
Ethnicity: □
□ American Indian □ Hispanic/Latino
□ Asian □ White/Caucasian
□ Black/African American Other: ______________
Gender: □ Male □ Female
Appendix B. Usability Test Task Lists
Paramedic/EMT
1) Find the patient’s emergency information
a. Locate the person’s name
b. Locate any health conditions that could lead to the person losing consciousness
c. Find a list of allergies the person has
d. Locate any medications the person is taking to avoid treatment conflicts
e. Find the insurance information section
i. Locate the person’s insurance company
ii. Locate the person’s insurance number
Diabetic User
1) Log in using:
Username: Bort Simpson
Password: test
2) Find Profile section to display user’s personal information summary
3) List treatments the patient took from 8/97 to 10/97
4) Locate list of medications the patient is currently taking
5) Locate the LifeLines for “Test Results”
a. Tap on the lifeline that represents the test result of Blood test
- Select the Related Events option
- Return to the previous screen
a. Locate the blood test lifeline again
- Select the Details option
- Locate the date of the blood test
- Locate the results of the blood test
- Return to the LifeLines screen
6) Locate the LifeLines for “Symptoms”
a. Tap on the lifeline that represents the symptom of Dizziness
i. Select the Related Events option
ii. Return to the previous screen
b. Locate the dizziness lifeline again
i. Select the Details option
ii. Locate the date of the dizziness symptom
iii. Locate the description of dizziness
iv. Return to the LifeLines screen
7) Locate the LifeLines for “Diagnosis”
a. Tap on the lifeline that represents the diagnosis of Influenza
i. Select the Related Events option
ii. Return to the previous screen
b. Locate the influenza lifeline again
i. Select the Details option
ii. Locate the date of the influenza diagnosis
iii. Locate the details of the influenza diagnosis
iv. Return to the LifeLines screen
8) Locate the LifeLines for “Treatments”
a. Tap on the lifeline that represents the treatment of Amandatine
i. Select the Related Events option
ii. Return to the previous screen
b. Locate the blood test lifeline again
i. Select the Details option
ii. Locate the side effects of the Amandatine treatment
iii. Locate the number of times the user should take the Amandatine treatment
iv. Return to the LifeLines screen
9) View LifeLines from 1993.
10) Log out
Appendix C. Post-Test Questionnaire
Paramedic Post-Test Questionnaire
1) The emergency information was easily accessible.
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Strongly Disagree Neutral Strongly Agree
2) Ease of finding patient’s current medications
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Extremely Difficult Neutral Extremely Easy
3) Ease of interpreting patient’s current medication
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Extremely Difficult Neutral Extremely Easy
4) Ease of finding information about patient’s current health condition
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Extremely Difficult Neutral Extremely Easy
5) Ease of interpreting patient’s current health condition
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Extremely Difficult Neutral Extremely Easy
6) What would make the application easier to use?
7) What potential problems may arise during actual use?
8) What features did you like or dislike about this application?
9) Please list any additional comments.
Diabetes Post-Test Questionnaire
1) I liked using this application
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Strongly Disagree Neutral Strongly Agree
2) The LifeLines are easy to understand
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Strongly Disagree Neutral Strongly Agree
3) The LifeLines are visually distinguishable
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Strongly Disagree Neutral Strongly Agree
4) The flow of data representation was comprehensible
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
Strongly Disagree Neutral Strongly Agree
Extremely Extremely
5) Ease of: Difficult Easy
|
Logging in |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Entering new medications |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Entering new tests |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Entering new symptoms |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Entering new diagnoses |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Interpreting LifeLines |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Finding information on LifeLines |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Finding information about medications |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Finding relations between LifeLines |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Using information to fill out medical history form |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Displaying information for the doctor |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
|
Transitioning between screens |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
N/A |
6) What would make the application easier to use?
7) What problems occurred during usage?
8) What features did you like or dislike about this application?
9) Please list any additional comments.
Appendix D. Specific Subjects Descriptions
Before each of the user tests, a quick explanation was given on the purpose of the application. In most instances with the diabetic users, the concept of LifeLines had to be explained as well.
Subject 1: <EMT>
Subject 1 is an eighteen to twenty-five year-old Asian male who has three years of EMT training. During the usability test, this subject did not have any difficulties locating the items that were asked for on the test because the subject quickly recognized the “paramedic” symbol on the main “Login” screen. After clicking on the symbol, the subject easily retrieved information about the patient. The entire procedure to complete the required tasks took only about two minutes to complete. The subject commented that although it may take extra time to locate the PDA, it might be worth it if the information provided in the application enabled the medical personnel to avoid a potentially fatal treatment (via knowing the patient’s allergies and current medications) to an unconscious patient.
Subject 2: <EMT>
Subject 2 is a Caucasian male between the ages of forty-one and sixty years. The subject is currently a physician but worked as an EMT for two years. Initially, the subject noted that he had very little experience with personal digital assistants, but this did not seem to be a hindrance in the task completion. Questions on the pre-test were answered based on the subject’s knowledge of diabetes and diabetic patients. The test began with the user having issues with the speed the application took to load a form and detailed questions about the purpose of the application. After further explanation of the application and its design, the user did not have any further issues with the interface. Once in the application, the user intuitively tapped on the paramedic icon first. The subject found the data requested with ease. When asked for opinions and comments on the post-test, the user felt that the data represented was appropriate and sufficient in an emergency situation. The subject had the concern though that looking up the information on the PDA is only going to be helpful if the patient is conscious because the EMT will mostly likely never think about looking in the patient’s PDA before taking emergency actions since there is no precedence or protocol. Also, the subject expressed concern that he understood the paramedic symbol, but the symbol may not be meaningful to everyone. The subject also pointed out that EMTs may not necessarily trust the information contained in the patient’s PDA.
Subject 3: <DIABETIC>
Subject 3 is a recently diagnosed [within the last five years] diabetic, Asian male patient between the ages of forty-one and sixty. Although this subject does not own a PDA, he has seen people using them, knows what they are, and plans to purchase one in the near future. This subject also reported that he goes to the doctor’s office once a year and does most of his diabetes monitoring himself with a portable blood glucose monitoring system. This subject displayed interest in having his medical information visually represented before and after the usability test. During the usability test, the subject indicated that it is harder to distinguish between a button and a picture (in regards to the paramedic symbol on the logon page). The subject also had problems initially because he did not realize that he could click on the individual LifeLines to open up another menu. However, after being told that the LifeLines can be clicked on, the subject did not have trouble going to the “Details” or “Related Events” screens. The subject had some difficulty in other tasks as well, including accessing the profile page, but indicated that with a little more use and familiarity, he should have no problems in completing the tasks.
Subject 4: <DIABETIC>
Subject 4 is a female between the ages of eighteen and twenty-five. She has had moderate experience with a PDA, but was very interested in the concept of using a PDA to keep a record of her medical history. She did comment on being able to see the password when she typed it in and complained that the username was case-sensitive. She had a lot of trouble trying to get to the “Details” and the “Related Events” screens because she didn’t know she was supposed to tap-and-hold a lifeline to evoke the menu with the options listed. Thus, she did not know the menu existed and could not perform the tasks. However, after telling her how to evoke the menu, she was able to easily access the “Details” and “Related Events” screens. She also commented on the other main menu, saying “Actions” was not a common menu title and therefore, it was not intuitive that she should look for options in the “Actions” menu. The subject took between forty to forty-five minutes to complete the tasks.
Subject 5: <DIABETIC>
Subject 5 is a male between the ages of eighteen and twenty-five. He has some experience with PDAs, but has never owned one himself. It did take some time for him to familiarize himself with the software. Initially, he had trouble returning to previous screen but when told that simply closing the current window would bring him back to the previous screen, he had no trouble. The entire process took him around forty-five minutes. The subject had great difficulty in interpreting and locating LifeLines because of their dense display on the screen. The subject also asked for an explanation of the LifeLines and their colors. Furthermore, the subject commented that the dates for the LifeLines were somewhat difficult to match with LifeLines (i.e. it was hard to see where the lifeline was in relation to the timeline displayed at the top of the screen), and it became increasingly difficult as you move down the screen.
Subject 6: <DIABETIC>
Subject 6 is a Caucasian female between the ages of eighteen and twenty-five. This user was actively critiquing the application during the test. On the login page, she noted that she did not like the password being shown as she typed it. Then on the main LifeLines page, she said that the screen was too clustered with the various LifeLines. She recommended expanding each category on a separate screen to be able to view the LifeLines better. She also had difficulty finding the “Details” and “Related Events” screen since she did not know she had to “tap-and-hold” a lifeline for the menu to appear. However, after telling her, she had no problems completing the related tasks. For the “Details” screen, she did not like aesthetics of the grey boxes nor did she like how we laid out the specific information within the boxes. She also did not like how we laid out the information in the profile screen. In addition, she did not understand why we only had one option in the menu. It took the user almost an hour to complete the tasks, however, most of the time was spent making comments and not on completing the tasks.
Subject 7: <FREQUENT PDA USER>
Subject 7 was tested in the Hinman computer lab without any other individuals present. The subject is a Caucasian male between the ages of eighteen and twenty-five and always carries his Toshiba pocket pc so is very familiar with various PDA applications. When given the same tasks as an EMT, the subject was initially confused and asked for the login name and password. It was not clear that the subject should have tapped on the paramedic symbol. After being told to tap the symbol, the subject proceeded to the profile and was able to complete all the tasks listed. This entire process took less than five minutes. After the test, the subject offered suggestions as how to make the profile screen more visually appealing: 1) allergies, medications, etc should not be listed out in paragraph format 2) there should be some graphical grouping for each category (i.e. he felt that the white space breaking the various categories was not sufficient and suggested adding lines between them) 3) there should be more colors. The subject also offered the suggestion of having written directions by the paramedic symbol to make it more apparent that non-diabetic users or EMTs should tap that symbol to access the patient’s profile.
Subject 8: <FREQUENT PDA USER>
Subject 8 is a female between the ages of eighteen and twenty-five. Her tasks were the same as diabetics. The subject has substantial experience with PDAs (previously owned a Palm pilot and currently owned a Hewlett-Packard Jornada) so she knew exactly how to operate PDA applications. The only problem completing the tasks were going to the “Details” and “Related Events” screen since she did know she had to “tap-and-hold” to get to the menu. She also thought that it took a long time for the menu to evoke. She also noted that when trying to find specific LifeLines, it could get frustrating for the user if the only means of doing so was clicking on all of them. She brought up a good point that during this phase, test subjects may not get frustrated since there are only four LifeLines per category, however, if there were more, it would get irking. As a solution, she recommended having a search function available. She also recommended having the details screen specific to each category rather than having grey boxes for the description for each of them. The total time to complete the task was approximately 30 minutes.