EHR System Technical Functionality vs. Usability
COMMENTARY
William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
The adoption of EHR systems has led to numerous complaints that they are difficult to use even beyond a learning period. These difficulties include entering patient information in the right place in the right format, being presented with or finding the right information, and having that information be logically organized such that it enhances patient care rather than detracting from it. Beyond mere annoyances, difficultly in use can lead to errors and inefficiency, and can be frustrating to the user. Some aspects that might be meant to facilitate use, such as drop-down menus, can actually degrade use when a wrong item is easily selected without additional feedback. Further frustration arises when the trainer or tech support shows the user that the desired task can in fact be accomplished, in some cases however clumsily. This can be followed by the all purpose instruction to just be careful, and to simply remember that, for example, the desired patient data is spread over several pages that are multiple clicks apart, and where going back is equally convoluted. There might also be a reminder not to inadvertently click “over there” because that will switch you to a different patient.
Such use challenges are distinct from assertions that an EHR system has inherent functional errors such as mixing up data from different patients, or losing information, or recasting data from what was inputted to what is stored and presented. A claim that an EHR system doesn’t work correctly can be characterized as a lack of technical functionality, while being excessively difficult to use is characterized by its usability. It can be noted here that EHR certification for Meaningful Use addresses only functionality, not usability.
The distinction between EHR system functionality and usability often leads to the binary application of blame. If the software isn’t capable of doing the right thing we can blame the software. If the software has the necessary capability but there is an issue with its use we can declare user error, and blame the user. This simple view ignores a long history of research and application in what is generally called human factors. The principles of human factors assert that if good results are desired, then things must be designed in a way that is consistent with reasonable expectations about how users are likely to perform when presented with certain design features. On the other hand bad design can create error, or fail to mitigate it. Error can also propagate such that problems with using one EHR system leads to errors in another.
In this regard the term “use error” (which I claim to have coined in 1995) is preferred over “user error” as a first conclusion when poor system performance is related to the means of use. Use error acknowledges that there was an issue related to how the user interacted with the system, but blame is withheld pending further analysis of why that interaction was less than desirable.
Good human factors design is first the responsibility of the manufacturer with respect to designing a system that truly meets the user’s needs. It must then become part of system selection criteria requiring real users to interact with the system and evaluate its usability. Only this combination will bring us systems that meet their promises.