accessible designs for personal health records

Activity 3: Expert Assessments of PHRs

We assessed three PHR systems from different market segments:

1. a PHR integrated with the EMR of a large hospital or medical center
2. a PHR integrated with the EMR used by a ambulatory practice
3. a consumer PHR relying primarily on patient entry of information, but with the potential to import/export data in standard file formats for interoperability.

We assessed each PHR for accessibility, functionality and usability.

Activity 3A: Assessment of PHR Accessibility

A primary goal of the Project is determining, and improving, the accessibility of PHRs for people with disabilities; this Activity is thus the most comprehensive of the PHR assessments.

Methods

The PHR systems were evaluated using semi-automatic tools designed specifically to assess the accessibility of Web pages or Web sites. These tools included the NCAM QA Favelet, the Web Developer Toolbar, Colorzilla and the WCAG Contrast Checker; as well as Firebug to manually inspect Web-page code for compliance with accessibility practices established by the Web Content Accessibility Guidelines 2.0 and Section 508 requirements. In addition to visual and code checks, reviewers evaluated PHR systems using assistive technology, including screen readers for both Mac (VoiceOver) and Windows (JAWS and NVDA) as well as screen magnifiers (Zoom for Mac; ZoomText for Windows).

An experienced accessibility expert supervised the reviews. Each PHR system was evaluated against a set of accessibility topics and given a "Pass" or "Fail" rating (see table 4).

Results

Overall the assessment provided interesting contrasts in accessibility. The hospital PHR was the least functional and least usable, yet was the most accessible, demonstrating awareness and an intent to meet established guidelines. Meanwhile the ambulatory PHR was the most functional and most usable, yet failed to meet almost any accessibility standards. The consumer PHR was quite usable despite failing to meet the specific accessibility criteria, and failed one crucial accessibility requirement: the entry of dates by people with visual and/or physical disabilities, a critical action required by almost every task managed by the system.

The results of the three PHR systems against 13 accessibility requirements are listed in the table below.

Each accessibility requirement and the test results of each PHR system are described in more detail below.

Keyboard Accessibility And Well-Defined Focus

People with physical disabilities who cannot use a mouse or other pointing device rely on keyboard navigation and control to interact with PHR systems. Additionally, Web pages must provide a focus that is easy to see around all links and controls, and over all backgrounds. Doing so makes it easier for keyboard-only users, especially those with visual impairments, to determine when links can be selected or when form elements are active and available for input. Both the hospital and ambulatory PHR provided good keyboard accessibility. The consumer PHR provided generally good keyboard access except for date-selection widgets, which were not keyboard accessible. This may seem minor, but a majority of patient data entry and other tasks in the consumer PHR required the entry of dates. Therefore the system would present a major task-completion barrier to the keyboard-only user. While unfortunate, this type of oversight is quite illustrative in demonstrating how an otherwise accessible site or application can fail when a single issue is not addressed.

Headings

Semantically, headings are used to denote the start of a new section on a page, or breaks between parts of a long document. However, for screen-reader users they can also provide a mechanism to efficiently scan the page in a manner similar to a sighted person, dramatically reducing the time required to interact with a Web site. Screen readers can sort heading information into a list, then users can scan the list and jump quickly from one heading to another. Only the hospital PHR provided consistent headings. The ambulatory PHR failed to provide any headings to its pages while the consumer PHR used headings inconsistently across and within pages.

Data Table Markup

All data tables need to have explicitly labeled header rows. If headers are not clearly indicated, screen readers are forced to guess at x- and y-axis information to help orient the user in the table. Authors should therefore guarantee accuracy by using appropriate table markup, which includes, but is not limited to, the use of the table-header element (<th>) on each header cell. Only the hospital PHR provided complete and consistent accessible data-table markup. The ambulatory PHR provided the correct table-header markup on table rows, but not columns. By contrast, the consumer PHR provided the correct table-header markup on table columns but not on rows.

Bypass Navigation Links

On any Web site that has groups of repetitive navigational links, or other large collections of links, it is always best to provide a method for screen-reader users to bypass those links. Otherwise, each time users visit a new page on the site they must wade through the links before locating the unique content of the new page. Only the hospital PHR provided a consistent method to bypass groups of navigation links. The ambulatory PHR failed to address this accessibility issue in any way while the consumer PHR provided an inconsistent solution.

Image Labels

Many websites use images and icons to communication information or functionality. Because screen readers cannot automatically identify the contents of an image to the user, or read aloud text contained within an image, all images must have a text equivalent that a screen reader can convey to the user. Text equivalents are typically delivered using HTML's alt attribute. Important images should have brief, descriptive alt text; unimportant images (such as purely decorative or spacer graphics) or redundant images should use null alt -- e.g., alt="" --, an indication to the screen reader to omit that image from the reading order. Only the hospital PHR provided sufficient text alternatives for images. The ambulatory PHR used an extensive range of icons yet failed completely to provide any image labels. The consumer PHR also failed to provide image labels.

Form Element Labels

Using a PHR or any interactive website involves the use of forms, where the user enters or edits information in text fields, radio buttons, check boxes, pick lists and pull down menus. While the label or title of each form element may be visually located adjacent to the actual element, form elements must also have explicitly associated HTML labels. Explicit labeling is the only way to ensure that screen-reader users will hear the correct label for inputs. Screen readers will guess if labels are not used, sometimes correctly, often incorrectly. All three PHR systems failed to provide consistent form-element labels. The hospital and consumer PHR provided form labels inconsistently while the ambulatory PHR failed to provide any form-element labels.

Color Contrast

Providing sufficient foreground/background contrast makes it easier for visually impaired users to locate and read information on a Web page. All three PHR systems failed WCAG 2.0 tests for appropriate contrast, but it is interesting to note that the palette for the hospital PHR is selected and configured by the hospital. Given this, the hospital PHR could meet accessibility standards for color contrast if customized correctly.

Avoid Using Color Alone to Convey Information

Some websites use color alone to convey important information or to get the user's attention: for example, the use of red text to denote a required field or to indicate some kind of alert. Color alone is not accessible to screen-reader users or some visually impaired users, so an additional means of identifying the information is needed to make it accessible, such as an icon (properly labeled), text or other symbol (e.g., an asterisk next to a required form field). Both the hospital and ambulatory PHR failed to provide more than color alone when conveying some types of important information. The consumer PHR rarely used color to indicate anything other than an incomplete field on a form.

Context Independent Links

Screen readers can sort links into list boxes for easy browsing. Screen-reader users also use the tab key to move the browser's focus from link to link on a page, or press keyboard shortcuts (such as the L key or the Tab key), listening as the screen reader announces each link. If a link is worded to be context independent, the user will still be able to identify the link target when the link is read aloud out of context. If the link is context-dependent (for example, "Click here" or "Read more"), the user will have no idea what the link target is. The hospital PHR provided many examples of context independent links, but still presented some inconsistency. The ambulatory PHR failed quite frequently in this regard. The consumer PHR did generally well, except for one page that listed links of available integrated health care applications that users could access. On this page the online PHR presented over 50 links with the text "learn more," but no way to identify what the user would learn more about.

Text Resizing

Most browsers provide the capability for users to increase font size on the web site/content being displayed. This is an important accessibility requirement for people with visual impairments. All three PHR systems responded to browser based text resizing.

Accessible PDF

All PDFs should be structured and tagged correctly in order to be accessible to screen readers or other assistive technology. Screen readers are especially affected by the way in which a PDF has been created; a PDF that is untagged, or is poorly tagged, can be difficult or impossible for a blind or visually impaired user to navigate. The hospital PHR did not provide any PDFs for PHR-related features or reports. The ambulatory PHR provided PHR-based PDF reports including a chart-export feature including history, labs and other very useful information. However, the PDFs generated by this system failed to provide even basic PDF-accessibility features. The consumer PHR provided the ability to create a chart-export summary, which would be useful in emergency situations, but it also failed to provide accessible PDF documents.

Time-out Warning/Extensions

If a Web page contains forms or other elements that require timed responses, users must be warned before the time limit is reached. Additionally, users must be given the option to extend the time required to complete an action. Typically this is done by presenting the user with a warning a few minutes before a session or activity is about to expire, while at the same time prompting the user to state that more time is necessary to complete a task. All three systems timed out, logging the user out and failed to provide a time-out warning or extension.

Activity 3B: Assessment of PHR Functionality

Even if PHRs are made accessible, they need to meet healthcare consumer expectations in providing useful functionality toward management of health. This is critical not just for people with disabilities, but for all healthcare consumers. We reviewed the three PHR systems (hospital, ambulatory and consumer) for functionality including the types of patient information stored and functionality supporting the management of that information and communication and data sharing capabilities.

Methods

Each PHR system was reviewed screen by screen with an exploration of all features and options. An inventory of functionality was compiled based on two types of functionality: 1) Information and Information Management and 2) Communication and Information Sharing.

Results

None of the PHRs achieved the detailed and sophisticated functionality described by our interview participants and rated as important by our survey participants. Table 17 presents a compilation and comparison of the information contained within each PHR and associated features supporting the management of that information. Table 18 presents the communication and information sharing functionality of each PHR.

The consumer PHR presents a number of constraints in this type of comparison. While it did provide a broad range of patient information and associated tools and resources, it is not directly integrated with a provider EMR (hospital of ambulatory). Though this system does provide import and export functionality, utilizing standard interoperable file formats, we suspect it is rarely used due to the current state of interoperability in health information technology. In addition, without direct integration to a hospital or ambulatory PHR it cannot support health tasks based on communication and collaboration between patients and providers. Given all this, this system is better suited to a consumer who is dedicated to entering, compiling and maintaining their own independent medical record.

Full information access and the ability to add/edit/annotate information were critical requirements to our interview participants. Both the ambulatory and consumer PHRs provided a comprehensive set of patient information categories. Though neither achieved the full access described by our interview participants, each provided a number of tools to allow consumers to add, annotate or even correct the information in their record. By contrast the hospital PHR was far more limited in the types of information it presented to consumers (see Table 17) and it provided virtually no options for patient-entered information anywhere in the record.

Other critical requirements from both our interviews and survey were resources and tools supporting communication and collaboration between providers and any person involved in managing a patient's care. While the hospital and ambulatory PHR provided simple messaging between the consumer and provider, neither could be described as supporting the communication and information sharing requirements of care coordination.

The availability of trusted healthcare education content, directly via the PHR, was also an important requirement described by our interview participants. Though third-party healthcare education content systems can be integrated with PHRs (some for free) none of the three systems provided any patient education content save a few simple PDF files available from the medication section of the ambulatory PHR.

Access to a wide variety of health management tools was another important requirement from our participants. The hospital and ambulatory PHR did not provide any such tools, but the consumer PHR provided a number of tools within the system and provided integration with scores of third-party health applications. While we did not assess the functionality, accessibility or usability of these applications, we feel this type of variety and exposure to potentially innovative and useful applications, integrated with the PHR, would not only meet, but perhaps exceed the types of tools described by our participants.

Our interview participants also described requirements for the PHR to support insurance-related tasks (such as referrals or pre-certification) as well as information on costs and coverage options. All three systems provided for a simple record of the consumer's insurance provider, policy number, etc., but no other information was provided and costs were not addressed in any way. Both the hospital and ambulatory PHR did support referral requests, but the burden was on the consumer to locate and enter specialist provider ID numbers, procedure and/or diagnosis codes as well as insurance policy numbers -- even if that information was already stored elsewhere in the PHR.

Our interview participants also described PHR functionality to support the recording and management of medical equipment. This included disability related equipment, such as expensive and heavily modified electric wheel chairs, but also common home health equipment such as monitoring devices, beds, shower chairs and more. The ambulatory and consumer PHR both provided an assistive device section, but it was not clear if this was intended for implant devices (pacemaker, artificial knee, etc.) or accessibility related equipment or both. While the ambulatory PHR provided a simple text field, the consumer PHR provided a range of discrete fields for both the device (model number, serial number, etc.) and vendor/manufacturer.

Activity 3C: Assessment of PHR Usability

Even if PHRs are made accessible and meet health consumer expectations in providing useful functionality, they need to be usable. Usability refers to the design of the system in supporting the user in understanding and discovering the structure, information and capabilities of the system, and using the system efficiently and effectively in all the tasks the system was designed to support. We reviewed the three PHR systems (hospital, ambulatory and consumer) for usability.

Methods

The usability reviews were performed utilizing two techniques: a heuristic review and a cognitive walkthrough. A heuristic review involves comparing the system to established principles of good design and user interaction. The cognitive walkthrough is achieved by having a reviewer perform tasks supported by the system and identifying any potential usability issues in the process. While both represent established and widely adopted usability methods, neither includes direct participation/observation of end users and each can only provide subjective data based on the opinion and/or skill of the reviewer.

The purpose of our assessment of these PHRs is to support our future design activities by attempting to assess the "current state" of PHR usability and is not meant to be a comprehensive usability assessment of these three PHRs. In addition, it is our intention to avoid singling out any particular vendor for criticism (or praise) and to protect the vendor identify of the systems we assessed. Given this, our review does not include screen shots or even detailed descriptions of any of the three PHR systems, but covers general concepts, all aimed toward informing our design work.

Results

None of the three PHRs achieved the level of usability often demonstrated in consumer-focused information technology, consumer electronics, desktop computing, mobile computing or online systems supporting communication, social networking and e-commerce. Each of the three PHRs presented a range of usability issues described below.

Navigation

Navigation refers to the system's organizational structure and user interface components dedicated to both understanding and utilizing the structure of the system toward discovering information and/or performing system tasks. The consumer PHR provided a somewhat contemporary and efficient navigation structure, though it could be more efficient and consistent. Both the hospital and ambulatory PHRs presented navigation systems that failed to apply commonly adopted techniques used in many websites and applications; the ambulatory PHR was superior in top-level navigation while lacking adequate secondary or other level navigation. As a result, each PHR has the potential to be confusing and/or inefficient. While this describes the current state of these systems we feel that if/when these systems evolve to include additional functionality (either that described by the Meaningful Use requirements or from requirements generated by research such as this project) the navigation schemas of these PHRs would have difficulty managing a more complex information hierarchy. The complexity and essential nature of PHRs require a carefully and systematically designed information architecture at every level.

Information Display

Within each section of the PHR (medications, labs, history...) only the consumer PHR applied well-designed information displays. Tables of information were clearly labeled and a consistent table design was used throughout the system. By contrast both the hospital and ambulatory PHR presented inconsistent, incomplete and poorly designed information displays.

Forms and Data Entry

Of the three PHRs, only the consumer PHR demonstrated well-designed forms and data entry (though as discussed above, date entry was inaccessible). Beyond providing consistent and well-designed forms, the system supported users in a number of tasks. For example, when entering a new medication or diagnosis, the consumer PHR provided type-ahead lookup features that were very fast and responsive. This made entry more efficient and potentially accurate and descriptive as well. The ambulatory PHR had a number of sections with consumer entry options, but the corresponding entry forms were designed poorly and inconsistently across the system. For entry of healthcare history information, the ambulatory PHR required specific dates including family history, surgical history and more. It is highly unlikely a consumer would have memorized the exact date, for example, their grandmother had a heart attack or that of their tonsillectomy as a child. By contrast the consumer PHR provided a number of options to enter year, age or even a range of years.

The hospital PHR provided virtually no patient information entry, but did require patient data entry for scheduling, referrals and other tasks. Like the ambulatory PHR, these forms were both poorly designed and inconsistent across the application. Beyond form design, both the hospital and ambulatory PHR presented unnecessary demands on the consumer in submitting a referral request. For example, in these systems the consumer was required to locate and enter provider ID numbers and diagnostic codes. Where and how they could locate this information was not at all clear. (In fact, the specialist must provide this to the patient.) In addition, the consumer was required to re-enter information already stored in their medical record such as date of birth or insurance policy number.

Communication Tasks

Due to a lack of provider system integration the consumer PHR was incapable of supporting messaging. Electronic messaging was however a central feature of both the hospital and ambulatory PHRs. Despite no shortage of excellent and efficient designs for desktop and web-based email systems, each PHR presented a poorly designed and inefficient messaging system. As a result, every aspect of managing messages was cumbersome and confusing. Beyond basic design, these two systems failed to apply innovative features that would help consumers more effectively communicate with their providers. For example, if a consumer had a question on a particular medication or lab result, she would have to copy-paste or somehow remember this information as they navigated from that section to the dedicated messaging section. One of our interview subjects described a potential feature where such messaging would allow the user to automatically reference the specific information in the chart for which she had a question.

Miscellaneous Issues

There were a few instances that seemed to demonstrate a lack of comprehensive design and/or quality control. While technically “bugs,” these types of issues can impact usability. For example, the ambulatory PHR actually contained data on a complete medication history, including current and past medications, but there was no way to view the past/inactive medications from the actual system. Instead, the diligent consumer might discover that in the export to PDF function, there is the option to export all medications and within that PDF is in fact a list of all past medications. The same system provided a robust past medical history entry section, but this included a lengthy OB/GYN section when the patient was male. Issues like that are expected in paper record systems, but well-designed electronic systems can readily improve the user experience.

Health Task Support

Related to the navigation issues described above is the overall information structure of the PHR. While separation of chart sections including problem list, medications, labs, history, etc. is a long-standing design derived from paper chart tabs, such designs may be of limited value to consumers and a more comprehensive and cohesive approach could be beneficial. For example, a consumer might have a diagnosis of Hyperlipidemia, cholesterol panel lab results for that diagnosis and a medication, a statin, prescribed to manage the diagnosis. In the current design of all three PHRs, that data is compartmentalized across three sections: Problem List, Labs and Medications respectively. We believe that PHR designs based on some disease or condition might be more effective in helping consumers understand and therefore participate in managing their own health.

Previous Section: Web-based Survey | Next Section: Next Steps