|Home | About | Journals | Submit | Contact Us | Français|
Insulin is a highly scrutinized drug in hospitals since it is both frequently used and high risk. As the insulin ordering process makes a transition from pen and paper to computerized provider order entry (CPOE) systems, the effective design of these systems becomes critical. There are fundamental usability principles in the field of human–computer interaction design, which help make interfaces that are effective, efficient, and satisfying. To our knowledge, there has not been a study that specifically looks at how these principles have been applied in the design of insulin orders in a CPOE system.
We analyzed the usability of inpatient insulin ordering in three widely deployed CPOE systems—two commercially marketed systems and the U.S. Department of Veterans Affairs VistA Computerized Patient Record System. We performed a usability analysis using aspects of three different methods. Our first goal was to note each instance where a usability principle was either upheld or not upheld. Our second goal was to discover ways in which CPOE designers could exploit usability principles to make insulin ordering safer and more intuitive in the future.
Commonly encountered usability principles included constraints, obviousness/self-evidence, natural mapping, feedback, and affordance. The three systems varied in their adherence to these principles, and each system had varying strengths and weaknesses.
Adherence to usability principles is important when building a CPOE system, yet designers observe them to varying degrees. A well-designed CPOE interface allows a clinician to focus more of his or her mental energy on clinical decisions rather than on deciphering the system itself. In the future, intelligent design of CPOE insulin orders can be used to help optimize and modernize management of hyperglycemia in the hospital.
Computerized provider order entry (CPOE) has existed for decades and is continuing to spread, its growth in the United States now propelled by hospitals’ desire to meet “meaningful use” criteria tied to financial incentives.1 Many studies have shown that CPOE can improve patient safety by eliminating sources of error in medication delivery, such as misinterpretation of handwriting, and by alerting providers to drug–allergy or drug–drug interactions.2 In addition, CPOE opens the doorway to helping providers make better, more evidence-based clinical decisions through clinical decision support.3 More caution has been expressed about the benefits of CPOE, with newer studies showing less obvious safety benefits and the introduction of unintended negative consequences.4–7
Usability may be one of the key aspects of CPOE that stands between beneficial and detrimental outcomes. The International Organization for Standardization defines usability as “a set of attributes of software which bear on the effort needed for use and on the individual assessment of such use by a stated or implied set of users.”8 The International Organization for Standardization also defined usability as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.” For CPOE to be “effective,” it must allow the clinician to choose the correct medication and dosing instructions. Khajouei and Jaspers8 note that, for CPOE to be “efficient,” this must occur with the minimum expenditure of resources “in relation to the accuracy and completeness of the order.” “Satisfaction” refers to the clinician’s subjective feelings about the experience with the CPOE system.
In commerce, Web sites must be designed to meet these three goals or they risk losing customers to their competition. First-time users of Amazon.com are generally able, without prior training, to order the product they desire effectively, efficiently, and with satisfaction. This occurs because Amazon.com takes advantage of dozens of design and usability principles.9 When first encountering CPOE, the clinician cannot avail himself of competing options, as he requires the CPOE system to complete his patient care task. Thus poorly designed CPOE can lead to physician discontent, frustration, and slower, less efficient patient care. In 2002, a major California medical center suspended its implementation of a CPOE system because of physician dissatisfaction.10
Khajouei and Jaspers8 systematically reviewed the literature on the impact of CPOE systems’ design aspects on usability, workflow, and medication ordering. However, to our knowledge, no usability study has specifically addressed the use of CPOE for insulin orders. Insulin is of particular interest in that it is both high risk and frequently used in the hospital setting. Insulin administration errors pose a serious problem for hospitalized patients and are responsible for 39% of the serious medication errors causing harm to patients.11 Insulin ordering offers an opportunity to examine CPOE and how its usability and design affect the outputs of medication orders and ensuing patient care.
One aspect of insulin ordering where there is great interest in system redesign to influence physician behavior is the insulin sliding scale. A large body of clinical literature documents the importance of avoiding reflexive use of the insulin sliding scale as well as clinicians’ inability to escape this practice. Endocrinologists widely agree that clinicians should more frequently assess and update their glycemic management, including use of nutritional insulin doses instead of just correctional insulin (the sliding scale).12–14 However, despite attempts to teach and train physicians to manage hyperglycemia more actively, use of the sliding scale remains prevalent.15,16 Rational and intelligent design of insulin orders in a CPOE system may be a helpful tool in overcoming this clinical inertia. Even if computerized insulin orders are medically accurate, if not built and designed well, they may fail in this purpose.16
In this article, we examine inpatient insulin orders from three different CPOE systems, with three major goals. First, we will highlight aspects of each system with regard to its usability, noting instances where usability principles are upheld or violated. Second, we hope to help users of CPOE systems understand the inherent design choices and how each choice affects their interactions with the CPOE system. Third, we want to help designers of CPOE systems understand the implications of their design choices, especially with regard to the unique aspects of insulin ordering.
We selected three commonly used CPOE systems for this study, two commercially available systems that we will refer to as system A and system B and the U.S. Department of Veterans Affairs VistA Computerized Patient Record System (CPRS). These particular systems were selected because each is widely deployed and they represent systems from both the private and public sectors. We chose three usability testing methods that have been described as the “testing methods most often used.”17 Using these methods, we assembled a matrix noting each instance where a usability principle was either upheld or violated in inpatient insulin ordering with CPOE. We used the heuristic method to compare the usability of each of these three systems to a widely agreed-upon set of heuristics, or rules, of usability. We used the cognitive walkthrough method by performing a set of discrete tasks within a system. We also used the think-aloud method by actually thinking aloud while performing each task during the cognitive walkthrough.17 We then scrutinized our results matrix to find which usability principles were most commonly encountered.
System A’s successful use of natural mapping and self-evidence (Table 1) makes its insulin orders the easiest of the three to navigate. The design reminds the user of a familiar paper order form (Figure 1). There is a tabular format with columns for the time of day and rows for type of insulin. This format matches clinicians’ mental image of insulin ordering. Insulin orders in the CPRS (Figure 2) and system B (Figure 3) instead appear in the same format as any other order in those systems, failing to reflect the uniqueness of insulin ordering.
Tabs are another important and effective design feature. Krug9 believes that tabs are excellent because they are “self-evident,” “hard to miss,” and “suggest a physical space.” Tabs are a rare example of a physical metaphor on a computer screen. Both system A and system B use tabs well, making the active tab’s color bleed into the page below, showing a physical connection between the two, distinct from the tabs in the background.
System B uses another effective design convention, with small arrows that point sideways to tell the user that there is a submenu behind that selection (Figure 4). When opened, this arrow changes to a downward arrow. This is a common convention that requires no mental effort for a user to decipher.
One place where system A shows ineffective design strategy is on its tab B (Figure 5), labeled “Meal Time Correctional Insulin.” Here, the headings at the top, written in blue font, are not clearly connected to the table below, in black font. While font color was used to denote a difference, the designers also could have used vertical lines effectively so that the user could immediately, without thinking, connect the insulin units to the blue headings above. Another problem in tab B is that the type of correctional insulin chosen is not clear to the user. While it is in fact the same type of insulin as chosen in tab A, the user might have to do a few clicks back and forth between tabs A and B to discover this fact.
The three systems use feedback to varying degrees. Effective use of feedback is critical to let the user know that his action has ended in a result or made a change in the system. In the CPRS, feedback is used when buttons turn blue and are underlined after they are clicked.
System A lacks effective feedback to the user in that the user can click “save and exit” after completing tab A without ever looking at tabs B and C (Figure 1). There are prechecked orders on tab C, meaning that the user is signing orders without ever even seeing them or knowing they exist. The system should have some feedback to let the user know that he has unwittingly chosen these orders. The system might instead have chosen to force the user to move to the “next tab” until he has seen all of the tabs and can then “save and exit.”
System B effectively uses feedback by displaying the chosen dosage of insulin on the screen, 2 units in this example, immediately after the user enters the information. However, it then displays both the breakfast and lunch doses of insulin as “starting today at 1656,” giving no indication or feedback to the user that these are in fact two distinct orders and not erroneous duplicates (Figure 3).
Both system A and system B effectively use affordance. In system A, fields where an entry is required are shaded yellow (Figure 1). In system B, required fields similarly use affordance, displaying a red stop sign with an exclamation mark (Figure 3).
Constraints are used frequently by these systems both effectively and ineffectively. Norman18 writes about constraints and how they are used to limit the user’s choices to make it impossible to do the wrong thing. Alternatively, a constraint can be designed to signal the appropriate action. One type of constraint used by CPOE systems are defaulted orders. This would have been useful in system B’s “Notify Physician Parameters,” where it is likely that these three orders are chosen by nearly every clinician using the order set (Figure 3). Prechecking these three boxes could have cut down on mistakes as well as save time.
System A makes more effective use of constraints for the same types of orders, going even further by removing the checkbox next to these orders, making it impossible to deselect them (Figure 1). The designers, knowing that these orders should be chosen every time, did not want to allow the user to deselect them. This intentional choice saves the user the cognitive workload of having to pause for even a moment to consider whether these orders should be selected. In tab B, system A has pre-selected the sensitive correctional insulin scale based on the patient’s body mass index (Figure 5). This is an example of more advanced decision support, potentially saving the user time, standardizing care, and preventing user error. However, this feature could also introduce error, for example, if the body mass index was incorrectly calculated based on an incorrect height entered into the system.
Another type of constraint is a “corollary order.” With “corollary orders,” selecting one option automatically opens up more orders that the system deems linked to the first one. In the CPRS, when an “acute care insulin sliding scale” order set is selected, the user receives an automatically progressing list of prechecked orders (Figure 2). This list includes the insulin orders, PRN glucagon orders, and “call house officer” parameters. Once the preselected list is opened and the user begins navigating through, the user is actually unable to do anything else until each order in the entire set is either confirmed or rejected. This design is very effective for standardization, guiding users to select the exact same orders every time with very little thought necessary. However, in cases where customization is desired, there is no signal to the user or prompt for this to occur. Of note, this “automatic” order set in the CPRS does not include orders for finger stick glucose checks. It seems rather unlikely that a user accustomed to quickly clicking through the order set is going to realize that a separate order needs to be placed for finger stick glucose checks.
The dosing schedule choice in the CPRS shows both constraints and a lack of constraints. While insulin is nearly always given in one of 3 or 4 dosing schedules, the system presents a scrolling list of over 50 dosing schedules, the same list presented for any medication. Shortening this list could both save time by diminishing the cognitive workload of the user and also reduce the potential for error. Error could occur here either by a provider accidentally choosing the wrong dosing schedule or by mistakenly believing that all these options are realistic and correct choices. Koppel and colleagues6 surveyed house staff and found that one common error caused by CPOE was the mistaken belief that, if an option is present, it must be viable. The CPRS does try to avoid errors by preselecting the “QID AC+HS” dosing schedule, which is likely to be the most frequent selection.
A potentially dangerous lack of constraint exists within the CPRS. In the dialog box where a regular insulin sliding scale order is written out, there is a free-text section where a provider can change the insulin doses that correspond to each blood glucose range. Since this is a free-text section, there is no limit to what number can be placed here and thus no limit to how much insulin could be ordered. One of the primary advantages of CPOE is dose-range checking, which is absent here.
In system A’s tab A, a user could potentially choose multiple types of short-acting insulin. A constraint could have been used here to allow only one type of short-acting insulin to be chosen (Figure 1). The designers chose not to do this, allowing for the rare clinical event where a provider might want to order multiple types of short-acting insulin. This raises a question that challenges many areas of CPOE beyond insulin ordering. Should constraints be designed in the system to prevent a provider from doing something that is usually improper but rarely might be correct?
System B takes a different approach from system A and the CPRS when it comes to preselecting correctional insulin doses. Though the user can open a submenu for low, medium, and high correctional doses (Figure 4) and there is an instructional guide at the top once the submenu is opened, the user must still click on each individual insulin order. This process of having to make multiple individual clicks rather than a single click to place a group of related orders may introduce a relatively high risk of error.
While both system A and system B clearly remind the user as to which patient’s chart they are placing orders in, the CPRS lacks this critical safety feature. Potentially adding to a user’s frustration would be the possibility that the user would have to click through the entire “automatic” order set only to realize that the work was completed in the wrong patient’s chart, and now has to start over from the beginning.
The CPRS falls short aesthetically compared with system A and system B. This is not important merely for shallow reasons. An amateurish-looking system can diminish the system’s stature to users, making them less tolerant of design flaws.9
Our analysis shows that many simple yet powerful design choices are inherent in making insulin orders in a CPOE interface effective, efficient, and satisfying. As we have shown, these three systems vary in their use of natural mappings and self-evidence, affordance, feedback, and constraints (Table 2). Each of these principles, when applied appropriately, can be used to streamline the user’s experience with the interface. When these principles are either not considered or used indiscriminately, the user’s experience suffers. One might imagine system B being built with far more constraints (e.g., “red stop sign” hard stops), forcing the user to fill out every field, even if not absolutely necessary. This would significantly slow down the user from completing his desired task.
We also discovered that system A is the only one of the three to use natural mapping and self-evidence, displaying an insulin-ordering screen that matches a user’s mental image of insulin orders. The other two systems increase the user’s cognitive workload by choosing not to display the orders in a standard insulin-type versus time-of-day format. The user must then spend mental energy not only deciding on the proper insulin dose for his patient, but also figuring out how to use the system to order that dose. The user’s time and cognitive effort are better spent making the right medical decision, not wasted on figuring out how to actually place the insulin order. Horsky and associates20 quantified the breakdown of tasks required to use a CPOE system and showed that users spent twice as much effort on system operation compared with patient-centered clinical reasoning.
We previously discussed the desire to help physicians take a more active role in hyperglycemia management, moving away from the clinical inertia of the sliding scale that persists day after day during a hospitalization. An oft-quoted principle of computer interface design is “don’t make me think,”9 meaning the design of an interface should intuitively allow or even lead the user to reach an end result. We gave the example of the sliding scale orders of the CPRS, which allow a user to move through rapidly without needing time for thought. One might argue that, in certain cases, CPOE should be different. Perhaps physicians should be encouraged to think more about each click they make in a CPOE system. The crucial point is that the user’s time is better spent making medical decisions with the help of the interface rather than trying to decipher the proper use of the interface. At one end of the spectrum, we can design systems to be fast and efficient so that a user can move quickly through his orders without pause. At the other end of the spectrum, we can design systems that intentionally slow users down and force them to think at each step. The optimal system might be one in which these two opposing principles are blended in a way that maximizes speed and efficiency for the user while minimizing potential patient harm. This balance is especially important for insulin orders. Intuitive electronic insulin orders will still be efficient and quick but will also guide the physician to reassess daily insulin needs.
Without special configuration, none of the systems present the user with recent finger stick glucose values while selecting insulin doses. Presenting these data may help the user be more proactive with hyperglycemia management. Busy users are less likely to toggle back and forth between screens to find this information. We believe that, in conjunction with improved insulin orders, it will be vital to improve information display about glucose management. This will require the design of creative and intuitive graphical displays that help physicians process information rapidly and accurately.
One might imagine a CPOE system that recommends suggested changes to daily insulin doses based on automatic calculations. A common fear is that this design might lead to litigation against the software vendor if an adverse clinical outcome occurs because of software miscalculating a dose. However, under the “hold harmless” clause, medical software companies enjoy a relatively large amount of protection from liability when their product is implicated in bad patient outcomes. One might expect that, given this legal protection, vendors will be willing to innovate in driving guided management of hyperglycemia.21 How the “hold harmless” clause is interpreted may shape future development of more advanced clinical decision support for insulin orders.
These three widely used CPOE systems varied in their adherence to usability principles in the area of insulin orders. Some of the most commonly encountered usability principles were constraints, natural mapping, self-evidence, affordance, and feedback. These principles are critical to the successful design and use of CPOE systems and yet are observed to varying degrees. Insulin is unique in being both a high-volume and high-risk medication and should be at the forefront of efforts to optimize CPOE design and clinical decision support in the future. Clever attention to usability principles might help end routine use of the insulin sliding scale. Optimal design will require more collaboration between people from multiple backgrounds, including human-factors engineers, sociologists, psychologists, cognitive scientists, interaction designers, nurses, and physicians.
In all figures, patient names and other identifying information are fictional.