EHR Design: Default Values as a Cause of Errors

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.



  1. Jerome,
    With respect to the concept of default values impacting errors, the most egregious design error within our acute care EMR is that medications are built and displayed to physicians by product. As such, physicians can be displayed an unwieldy number of choices for the selection of medication because of the variety of preparations and dosages through which the medication can be provided to the pharmacy by the manufacturer (i.e. 10, 20, 40, 80 mg strengths; tablet, capsule, INJ, IV, Soluset, etc.).
    As a physician, the easiest (and likely most reliable) workflow is for me to select the medication I desire to provide to the patient, then the dosage and method of delivery followed by the time parameters. The CPOE system could then run all necessary interaction checking (DrugDrug,DrugAllergy,DrugLaboratoryValue,DrugProblem, etc.) and return any conflicts so identified system and enabled by the institution. The pharmacy would then identify the proper product to which to match the physicians order and provide to the nurse responsible for administration of such medication.
    A build in this manner would eliminate much of the product based default dosing strings present in today’s CPOE systems. This is not to say the issue could recur through the utilization of orders sets or favorites but be helpful for those errors occurring outside of these situations.

    1. Matthew, thanks for your comment. What you describe does seem to be off-putting. It may be that the drug display is very close to the data as they exist in the underlying drug database. If so, then a few well-designed queries and programming logic could fix the problem. This is a perfect example of where user-configurable display options would make good sense.

      1. Jerome,
        You are exactly correct. The drug display is linked directly to the drug data as it exist in the pharmacy database design. We have the ability to map the drugs in a custom manner but then lose all of the back-end business/financial tools that are leveraged through drug linkage at the end user interface. Additionally, changes could impact other downstream users who could encounter confusing medication display issues. We have explored overlay products but there are significant interface build and maintenance concerns, which we have determined have the potential for greater harm than the current scenario.
        Ultimately, we have resolved to work with our large EHR vendor to improve future iterations of the product.

        1. Matthew, you are describing what appears to be a classic case of tight coupling between the database and user interface from software engineering 101. Solving the problem in code while maintaining all current benefit is doable assuming the EHR itself is not tightly coupled.

  2. Jerome, You don’t even mention things like defaulting to a normal exam under physical exam section of a providers interaction. At a prominent Cleveland facility using EPIC my wife and I have both had experiences of portions of a physical exam (abdominal) being recorded when they were not done. Not only fraudulent, but inaccurate, and a distortion of a patients record. I believe it was not an purposeful act of the provider to commit fraud. The ability to default to filling out PEx sections was selected because the actual workflow of doing it on the EMR was to onerous/time consuming, and the selection they made with a one time set up appointment for the EMR means they just don’t think about it when they commit the act of fraud.

    1. John, thanks for your comment. You point out another important example of default values causing problems, especially the downstream effect of being a source of potential fraud. Dealing with convenience vs accuracy is one of the issues that can appear to be minor but may actually be quite significant. Increasingly, I am finding that detailed workflow models are required to truly grasp all potential outcomes of a specific software feature/action. Currently, workflow modeling is used in healthcare mainly to model real-world situations at a fairly shallow level ( I think it is time to use detailed workflow models to capture real-world actions and then use those models for clinical software design.

Leave a Reply

Your email address will not be published. Required fields are marked *