User Centric User Research Experts Develop Guidelines for PHR Applications

Page 2 of 3

<< Previous Page 1 2 3 Next Page >>

Recommendations (Continued)

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.

<< Previous Page 1 2 3 Next Page >>