Back to overview

User Research Experts Develop Guidelines for PHR Applications

January 5, 2009

This article is re-posted from User Centric’s blog.

User Centric, Inc., (now GfK’s User Experience group) has identified several guidelines to be included in a working model for PHR interfaces that will facilitate user adoption. Based on a recent usability study comparing two existing online personal health record (PHR) applications, Google Health and Microsoft HealthVault, we gained a clearer understanding of which features currently work and do not work for users of PHR applications. (Neither Google nor Microsoft commissioned or participated in this study in any manner.)

While none of the PHRs studied had a perfect interaction model, the data motivated us to develop a series of best practices to be considered when implementing a PHR. The best practices discussed below are based solely on the issues observed and feedback given by participants, and leave room for further development toward a better PHR.

Since perceived simplicity and ease of use are keys to user preference, a PHR home page should avoid unnecessary visual complexity.

During the usability test, participants showed a strong preference for the layout of Google Health’s homepage when compared with Microsoft HealthVault’s homepage, mainly due to its simplicity. Google Health used a plain design on its homepage with only critical navigation and a few links prominently displayed. Participants found it “easier to access,” “less cluttered,” and “easy to navigate.” This focus on a few important points allowed users to quickly scan the information presented and find what they came for. A PHR should only display navigation and information necessary to complete core tasks on its homepage.

A PHR should provide strong cues to help users start entering health information.

Since new users will not generally be trained to use a PHR, a PHR application should be designed to support users from their first interaction with it. In the study, participants had difficulty with how to begin entering health information into all three PHRs and indicated they were looking for guidance from the applications on how to start this process. This is especially problematic because the main function of a PHR is to enter health information, and it should be easy for new users to jump in and enter health data. Instead, a PHR should provide a strong visual cue to the user for how to begin entering this information, such as a welcome page, large button or link representing a starting point.

Users should be able to add details about a health item (e.g., medication) immediately after entering its name. However, the number of detail fields displayed at one time should be limited to avoid overwhelming users.

The process of entering data should be as simple as possible, allowing users to enter items quickly while also providing an opportunity to enter details immediately. Both of the two PHRs tested proved difficult for participants in some aspect of data entry. For the most part, Google Health provided a quick path to entering the names of health items, but required users to navigate through multiple screens to add details about those items. On the other hand, Microsoft HealthVault allowed users to add details right away, but the sheer amount of entry fields displayed for each health item was overwhelming for participants.

Both ends of this user experience must be considered when designing the data entry process for a PHR. Participants overwhelmingly preferred to be able to enter details about a health item on the same screen as its name, so a PHR should support this process. However, the PHR must also be designed to ensure that its users are not overwhelmed with the amount of information they need to enter, possibly by limiting the amount of data entry fields displayed at one time.

Medical information should be presented without technical jargon.

Non-technical language should be used by in PHR applications whenever possible because participants were frequently confused by the medical terminology they did not understand. This was especially apparent when medical terms were used as field descriptions in Microsoft HealthVault. By using familiar terminology in links, field descriptions, and other areas, a PHR will provide users with a much clearer idea of what information they are being asked to enter, which will in turn help to ensure the accuracy of users’ health profiles.

Multiple methods of data entry and search (e.g., text entry field, A-Z list) should be supported.

Both Google Health and MSN HealthVault offered auto-complete functionality for users as they entered text, but only Google Health also offered an A-Z list of medical items to choose from. Participants from the usability study enjoyed Google Health’s flexibility, with some participants preferring to identify their specific medical issues by browsing through the A-Z list, and others preferring to use the text entry field. Both of these methods for entering health information should therefore be included in a PHR to accommodate a broad range of users.

Databases of health information should include multiple descriptions of the same health items to accommodate users’ differing levels of comfort with medical terminology.

Participants often felt constrained by the terminology suggested by the auto-complete functionality in both PHRs and sometimes did not know which item to choose when they did not understand the language used. Text entry fields should be flexible when identifying the medical item (e.g., medication, test result, condition) users type into them. The PHR database should be able to recognize whatever level of technical terminology users are comfortable with by storing multiple descriptions of the same medical item. It should also help to bridge the gap between layman’s knowledge and medical terminology by helping users to translate their understanding into precise medical terminology (e.g., suggesting spellings, filtering conditions via natural language prompts).

A confirmation should be displayed as items are added to a user’s profile.

During the study, participants were pleased with the immediate, detailed onscreen confirmation provided by Google Health as they added health items to their profiles. These users felt more confident that their items were added successfully. On Microsoft HealthVault, however, changes were not confirmed immediately for users, instead forcing them to click back to the Health Info or Home tab to view a list of all information types they had entered. A clearly visible confirmation of changes made to health items, such as a window, message, icon, or running profile, should be implemented in PHR applications to confirm successful data entry.

Profile summary information should be displayed on every page of a PHR.

As participants entered medical information in their Google Health profiles, they appreciated the persistent Profile Summary that updated every time they added a new item or made a change. This Profile Summary confirmed changes made to the profile as well as reminding participants what information they had already entered about themselves. This type of functionality would be a useful way for a PHR to allow users continual reference to their profile data.

Persistent navigation should be maintained throughout a PHR.

Many participants also indicated they found Google Health easier to use because of its redundant navigation model which utilized both tab-based navigation and a persistent left navigation menu. As a result, users could easily navigate from one health history item to the next by using either menu. PHR applications should include such persistent navigation to allow users to access any function on the Web site application from the each screen.

The ability to add a family member’s profile should be prominently displayed and easy to find.

While participants were able to successfully find the persistent link to add a family member’s health record on Microsoft HealthVault, they were very frustrated by its lack of prominence in Google Health. Since one of the core functions of a PHR is to enable users to input data not only for themselves but also for dependents, this ability should be emphasized in any PHR.
Some participants were also confused about the different labels for this function on each PHR, mainly due to the use of the potentially-confusing terms “record” or “profile.” A PHR that uses a clear label (e.g., “Add a Family Member”) would allow its users to avoid this issue.

Drug Interaction functionality should be included.

One of the most positively received functions throughout the study was the drug interaction tool available on Google Health. Participants also rated the ability to learn about possible side effects to medications quite highly in the features questionnaire administered at the end of the study. However, some participants said that these features would only be valuable if they came from a trusted source and they would likely look to their doctor as a primary source for this information.

If it is possible to integrate insurance information into a PHR, the tool should include the ability to find a doctor.

As they used the feature on Google Health, some participants were interested in being able to find a doctor, but this interest was limited to finding doctors within their health insurance provider’s network. Most participants found the link to see directions to a doctor’s location to be one of the most useful components of this feature. This feature, then, should only be included in a PHR if the tool was also able to integrate users’ insurance information to better target searches.

If an online PHR provides medical knowledge, the source of that information should be plainly shown to users so they can make their own judgments about the information’s reliability.

Some participants were interested in the Reference feature on Google Health that displays general medical information about a particular condition. However, these participants were also concerned about the reliability of the information, since the sources were not visible. A PHR should consider implementing a feature that displays medical information, but that also clearly links to its sources.

A PHR should allow users a secure link to their physician’s health records and allow them to both upload to and download from their physicians’ EHRs.

Sharing information with a physician was seen by many participants as a main reason for maintaining a PHR, making it an essential feature to include. Users should be able to import data from a physician’s EHR to avoid the repetition of data entry into the PHR. The ability to export and share family history information and symptoms with a physician or other family members was also highly praised, and should be supported by PHRs.

However, when accessing health information from a provider’s system, privacy standards may require a certain level of authentication which must be considered in the PHR design. It may be necessary for a PHR to employ secure passcodes or other means of reliably identifying individuals.

It is important to establish brand credibility, as it is a motivating factor for users to choose a PHR.

As mentioned earlier, participants said they would feel more comfortable with the information given in a PHR if it was from or endorsed by a known company or medical association. Brand credibility will help to ensure the success of any PHR.

A PHR should have easily accessible privacy agreements and other legal disclosures, in language that is simple to understand.

Some participants mentioned that terms of use and privacy policies were unusually important in the context of a PHR. Because these applications involve personal health information, a PHR should make certain to prominently explain to users how their data will be handled. However, it is also critical that this information be presented in a readable and simple format, so that users are not intimidated by pages of legal jargon.

Different types of users and their health needs should be consciously addressed when designing functionality for a PHR.

Because many participants saw significant value in using a PHR if they had a chronic condition, it is important that the ideal PHR is tailored to this type of situation. Although not included in a specific task in the study, the process of adding multiple updates to the same condition was not streamlined by any of the three PHRs studied, which may limit their utility for users with these types of conditions. Consider a user with a complicated condition like breast cancer. When this user initially sets up her PHR profile, she may want to input her cancer’s entire history, including related test results, treatment regimens, medications and procedures.

Then, each time the status in her health changes, the PHR will need to be updated. The current model used by all three PHRs in this usability study simply allows for new line items to a single category of information (e.g., condition or medication). The ideal PHR should allow users with such conditions to tie different types of information together under the umbrella of a single medical issue and enable easy updates.

Next Steps for PHR Applications

Performing usability testing on several popular PHRs allowed us to get a closer, more studied perspective on the user experience of PHRs as well as their most valuable features and functions. The wealth of data gathered from the research was used to inform the development of some design best practices for PHRs.We encourage further validation of the preliminary ideas suggested for these best practices above.

While there is still more to be learned in this domain, obtaining actual users’ feedback and experiences is an essential step to increasing the rate of PHR adoption. As a follow-up to the PHR usability testing described in this whitepaper, we conducted an online survey to gather further data on attitudes towards PHRs. Although analysis of the survey data is currently ongoing, several relevant trends have been identified.

One critical point is that survey respondents were not typically prepared to invest a large amount of time in configuring or updating their PHR. Most commonly, respondents were willing to spend between 10 and 30 minutes setting up their PHR and were willing to update it only monthly or yearly. This highlights the importance of the PHR user experience to adoption; if data entry is difficult or inefficient, the PHR may not be worth the user’s time.

Another interesting finding included the features that would most drive respondents to adopt a PHR. These were:
• Track immunization records
• Securely receive test results and information from your physician
• Share your health information with your primary physician
• Manage insurance information and medical bills
• Get reminders about regular checkups or recurring treatments.
Sharing one’s information with their physician was the only one of these features to be included on the questionnaire given during the usability testing, and it scored highly in both the testing and the survey. The other four features were among those newly introduced for the survey.

Read about our EHR usability consulting services.


Back to overview

Write a comment

*required field

Leave a Reply

Your email address will not be published. Required fields are marked *

Your comment*