We found that this medication error was due to the confluence of several factors, including errors by physicians in the use of the clinical information system, the absence of automated safeguards that help prevent errors, and uncertainty on the part of physicians about how to manage unusual ordering scenarios. The timeline and description of actions such as the activation or discontinuation of orders, decision points, time lags, and pharmacy intervention are represented in . Specific findings and their interpretation are described in the following sections.
Misconceptions about the Relation between Intravenous Volume and Time Duration
Potassium chloride can be administered intravenously either as a bolus injection or as an additive to drip fluid (such as saline or dextrose). The first Provider (A) intended to order KCl as an additive to D5W drip fluid and control the amount of drug to be delivered (in mEq) by specifying the rate and concentration and by limiting the total volume of IV fluid to 1 L . However, in the current CPOE application, drip fluid orders are specified only by their duration, with a default stop time period of seven days and cannot be limited by total volume of fluid delivered even when they contain medication additives. The IV fluid data entry screen includes a field labeled “Total Volume” to specify the size of the IV bag that should be used in the order. The meaning of “Total Volume” could be easily misinterpreted in the context of this order and in specific instances of time and dose combination would not represent the total amount of fluid that would actually be delivered to the patient.
The screen entry forms for drip and IV injection orders are visually very similar yet with important functional differences in constraining the amount of delivered medication: by time duration (drip) and by dose (IV injection). While there were only subtle differences in layout and appearance of data labels and values between bolus entry forms and drip order forms, the way default stop times were calculated by the system was very different, allowing for erroneous interpretation.
It is our contention, based on log analysis and user interviews, that the distinction between time-limited (drips) and amount-limited (boluses) dosing was not sufficiently clear from the way information in the entry dialog box was presented. In this case (orders 3, 5, 6, and 12), Provider A was apparently working under the assumption that entry screens for medicated drips behave the same way (i.e., controlled by volume specification) as IV bolus entry screens. This misconception was in part reinforced by the ambiguity of the “Total Volume” data label. There is no direct quote from the users about this issue, and the evidence is interpreted from logs and interviews.
Users without robust conceptual knowledge of the system may not realize that IV flow will stop only at the end of the specified time period (the default is seven days) and will exceed the displayed value labeled as “Total Volume.” Users may ascribe meaning to data labels or procedural concepts differently from what is assumed by the system designers. This divergence in interpretation is known in the human–computer interaction research literature as a user-designer mismatch.
Provider A also wrote an instruction to limit the dose to 1 L in the comments field . Free-text entries are “invisible” to the system's time or amount-related functions; a coded entry is usually necessary to activate internal processing.
Suboptimal Display of IV Bolus Injection and Medicated Fluid Drip Orders
While these two types of KCl administration may be ordered and run concurrently, our clinical information system does not effectively help the user manage this complex clinical scenario. At the time of the case, IV fluids were not displayed on the screen that physicians used most commonly to review the patient's medication list. As a result, IV fluid orders were seen less often by users, and medications administered via that route were more likely to be missed in the decision-making process for new orders.
This conceptual misunderstanding was also partly responsible for allowing the mistake in ordering to propagate through the system and across providers. Provider B was not explicitly informed by Provider A in the cross-coverage note that KCl was being delivered in the fluid drip because Provider A believed the drip had stopped running after 1 L of volume.
Misconception of Latest and “Dated” Laboratory Results
The covering Provider B on the second day checked laboratory data for serum KCl and read the latest available value, but that information was already 24 hours old and did not reflect the current medical condition of the patient. Even though the system shows the date and time of laboratory results, the display does not visually emphasize when the most recent available result is not in fact a current result. In active inpatient environments, where electrolytes are frequently ordered on a daily basis, providers often assume that the most recent values are from that day. In this case, Provider B incorrectly interpreted the information and followed up with an erroneous action (i.e., ordered another KCl injection). This error contributed to the magnitude of the resulting overdose.
Lack of Certain Automated Checking Functions
The pharmacy system detected an out-of-bounds KCl concentration error (100 mEq/L vs. the maximum recommended 80 mEq/L) from the electronic order but not the fact that this order was running for 36 hours, delivering an excessively large dose of potassium. Ostensibly, either the CPOE application or the pharmacy application could have detected that the patient would be receiving a large amount of potassium over a period of time. However, neither system was programmed to do this.
Inadequate Training of Safe and Efficient Ordering Practices
Computer logs of user activity indicated multiple attempts by both providers to enter orders into the system correctly, five and three times, respectively. These attempts are represented in as items 3, 5, 6, 10, and 12 for Provider A and as items 13, 15, and 16 for Provider B. For example, there are orders that were activated and immediately discontinued (3 and 4, 5 and 8, 10 and 11). Inconsistent interactive behavior in the repeated attempts suggested that the users could be engaging in trial and error rather than using a skilled strategy. Procedural knowledge gained mostly from experience is often not sufficient to ensure appropriate interaction with the system. Adequate training is necessary to learn efficient and safe ordering practices.
Specific Recommendations for System and Ordering Procedure Changes
The findings and analysis were referred for further action to the Hospital's Medication Safety and Informatics Committee responsible for addressing issues of medication safety that involve information systems. This committee includes representatives from the departments of quality assurance, pharmacy, information systems, nursing, organizational learning and training, as well as medical staff. The house staff, who write the majority of orders and are active users of the laboratory and medication review functions, were especially involved in the recommendations related to this case.
The Committee made the following recommendations for changes:
- Screens for ordering continuous IV fluid drips and drips of limited volume need to be clearly distinct so that the ordering of each is unambiguous.
- Screens that list active medication orders also should list IV drip orders.
- Laboratory results review screen needs to clearly visually indicate when the most recent results are not from the current day.
- Add an alert that would inform users, ordering potassium (drip or bolus) when the patient already has another active order for potassium.
- Add an alert informing users ordering potassium when there has not been a serum potassium value recorded in the past 12 hours or the most recent potassium value is greater than 4.0. This would reduce the likelihood of ordering potassium when the patient is hyperkalemic.
- Make other minor changes to increase the consistency of ordering screen behavior.
The Committee also suggested that training for the order entry application should not be limited to procedural knowledge but should emphasize conceptual understanding and safe entry strategies. Real working cases with various levels of problem difficulty should be used.
The recommendations were intended for the in-house team of software engineers, but it would be possible to suggest more extensive changes to the layout or appearance of screens and alerts that the vendor may consider for future versions of the software.