User Interface Considerations for Collecting Data at the Point of Care in the Tablet PC Computing Environment

Abstract

Collecting clinical data directly from clinicians is a challenge. Many standard development environments designed to expedite the creation of user interfaces for electronic healthcare applications do not provide acceptable components for satisfying the requirements for collecting and displaying clinical data at the point of care on the tablet computer. Through an iterative design and testing approach using think-aloud sessions in the eye care setting, we were able to identify and resolve several user interface issues. Issues that we discovered and subsequently resolved included checkboxes that were too small to be selectable with a stylus, radio buttons that could not be unselected, and font sizes that were too small to be read at arm’s length.

Introduction

Capturing clinical data directly from clinicians is considered one of the greatest challenges for successful implementation of electronic health records.¹ Making the user-interface natural to clinicians in a way that allows direct correlation between the patient chart and the underlying computer database is not a straightforward task. During the development of a fully-functional prototype for documentation of eye care on a Windows-based tablet computer, we found multiple instances in which standard user interface components were unsatisfactory for the requirements of the clinical computing environment.

Methods

During development of our prototype application, we employed an iterative design and testing process to review repeatedly the user interface with clinicians. During each iteration, ophthalmologists and optometrists from community and academic settings were encouraged to “think aloud” while using the system.

Results

Observations from Think-Aloud Sessions

We found that several user interface components supplied by standard development environments were cumbersome and ineffective. This lack of effectiveness was due to their small size and limited functionality. For example, users could not easily select radio buttons and checkboxes due to the small size of the selection area. Also related to size problems, users could not easily read the small fonts supplied by the standard development tool sets. In terms of functionality, the standard radio button requires that at least one item be selected. This functionality was not acceptable in the clinical setting where nothing should be selected if nothing has been observed. Also related to function, scrolling of the display is cumbersome since navigation on the tablet is performed using a stylus.

Approaches Used to Satisfy Data Entry Requirements

To overcome the limitations of the standard tool sets, we developed customized user interface components for our prototype application. We also chose a larger, more simplistic font for displaying text. We designed customized larger check boxes and larger radio buttons that could be unselected by re-tapping a selected button. We eliminated the need for scrolling by grouping like data items on multiple tabbed pages.

Discussion

Through this formative study, we discovered that the use of standard user interface components was unacceptable for supporting collection of eye care data directly from clinicians at the point of care. We devised customized user interface components that were more appropriate for point-of-care data collection. By using our customized components, users reported that data entry was more natural, more efficient and more satisfying. Additionally, data elements could be programmed so that they were directly represented in an underlying database.

Conclusion

The complex requirements for collecting clinical data and the limitations of the standard tablet computing environment require careful consideration of user interface design and component use. Creation of customizable user interface components is required to provide appropriate collection of clinical data at the point of care.