When designing software, a lot of care is given to squashing bugs. But what does one do when the design itself is the problem? Spotlight on Electronic Health Record Errors: Errors Related to the Use of Default Values, an article published by the Pennsylvania Patient Safety Authority, sheds much needed light on this subject. As the report notes, default values are usually considered a safety measure and not a potential source of errors. Yet, their study found that default values introduced errors into EHR systems.
The study was based on incident reports logged into the Authority’s Pennsylvania Patient Safety Reporting System (PA-PSRS). Of the 1,249 incidents recorded in the database, after review, 324 were deemed to be related to EHR default values. Here is an overview of the errors:
Of the 324 verified reports, 314 (97%) were reported as “event, no harm” (i.e., an error did occur, but there was not an adverse outcome for the patient), and 6 (2%) were reported as “unsafe conditions” that did not result in a harmful event. Two reports involved temporary harm to the patient that required treatment or intervention (user- reported harm score E); these events were associated with, respectively, acceptance of a default dose of muscle relaxant (which was higher than the intended dose) and an extra dose of morphine due to acceptance of a default administration time (which was too soon after the patient’s last dose). Two reports involved temporary harm that required initial or prolonged hospitalization (user-reported harm score F).
An analysis was also completed that looked at the origin of errors specifically in relation to EHR use or design. Here are the findings.
Problems originating in the use of EHR
Failure to change a default value (40%, n = 128). Reports explicitly mentioned that a user forgot to change a default value. Failure to enter a complete order, resulting in the inappropriate use of a default (5%, n = 16). Reports explicitly mentioned that a user entered an order that was missing certain order parameters and these order parameters were later filled in with default values.
Problems originating in the design of EHRs
User entry overwritten by the system in favor of a default value (6%, n = 19). Reports explicitly mentioned that a user had entered a value that was then overwritten by the system and replaced with a default value. Inability to change a default value (2%, n = 5). Reports explicitly mentioned that a user was trying to enter a value other than the default but was unable to do so.
From a software design standpoint, these errors can be difficult to prevent because they rely on people to make alterations. Using default values for medications or any type of order may seem helpful (e.g., assure some value is entered, save time by making common orders quick), but they make assumptions that, as these errors show, do not always hold.
Like many others, my encounter with this behavior happened with standard orders in hospitals. Protocols for anticoagulants come to mind. Systems are programmed to insist something be done, but are not necessarily smart enough to recognize a clear contraindication. As such, the responsibility for preventing errors falls back onto busy, distracted clinicians – not a great error prevention strategy.
Attempts to prevent default values from accidentally going unchanged or assuring that user entries are accepted by the system can be maddening. Using local validation rules (e.g., rules that apply only for that particular data entry value) makes error prevention difficult unless there is information available that provides “state” information as the process is occurring.
For example, if a user enters orders and does not change the default value, it could mean that he agrees with the default. Of course, it could also mean that he simply forgot. Resolving this issue requires more information about the ordering process itself. Here is one example of where workflow modeling can help in software design.
Workflows involve more than task sequences (see YAWL and Clinical Workflow Modeling, Part I: An Eye to Formalization). They also make use of data input/output, and resource interactions. Using workflow models, it is possible to explicitly model the user, the patient, the initial data values of the process, final data values, and the steps of the workflow.
If the workflow were to start with the selection of a patient, then navigating to the medication orders screen could instantiate all default values and mark them as the initial values for the data fields involved. As the user proceeds with order entry, the fact that the default values and the initial values are identical would be available to the system. Using this knowledge, the system could then raise an alert that asked if the default values were acceptable. This is one way of allowing default values while providing a mechanism to ensure that the user explicitly approves all defaults.
Of course, it is possible to design systems using a variety of UML diagrams (activity, use case, state, etc.) to represent process information, but workflow models using workflow patterns and Petri nets (especially colored nets) allow for much richer models within a single diagram. Even better, workflow modeling tools offer simulation features that permit visualization of process steps, which can be very helpful in looking for glitches.
Preventing errors in software, especially those related to default values, can be readily addressed through system designs that maintain an idea of state. And yes, this can be done without workflow models, but not as easily or as cleanly.