PDF File: 

HCT3_wp_lowenhaupt4.pdf

Accenture

As more and more physicians get comfortable with the technology, peer pressure is providing momentumto accelerate the move to an electronic environment for technophiles and technophobes alike.

Introduction

Building a clinical information system (CIS), especially as an instrument for integrating a hospital’s clinical and financial functions with each patient’s EHR, looms as a task for most healthcare providers. A vital consideration in implementing these costly and complex systems is how to get physicians to use them. A great deal of thought and discussion currently centers around establishing a flexible server-peer structure, a robust database architecture, and standardized communication protocols; but experience has shown that, very often, not enough thought or planning goes into providing a usable interface between the computer and the person who must use it.

The following case study of an EHR implementation was undertaken by a leading private practice health system in the Southwest. The “bumps in the road” experienced by this 13- hospital health system, and the lessons learned while traversing them, provide an instructive lesson in how to approach the physician/machine interface.

The Bumpy Journey

The project undertook implementing information system automation and clinical decision support at one of the health system’s largest facilities. This major transformation project included hundreds of hours of consulting time to re-think and re-design clinical processes. The first deliverable was an online admission history and physical assessment form for deployment in inpatient nursing units. The second deliverable, 13 months later, included major transformations of processes from printed charts and reports to online documentation, including medication administration and post-discharge scanning of all remaining paper documents. Physicians were required to provide an electronic signature for all medical records. The elimination of as many paper documents as possible was established as a major system benefit. The strategic plan called for all clinical users to view clinical results online. The plan also established a direction toward computerized physician order entry (CPOE), evidencebased practice guidelines and further conversion of clinical documents to electronic records.

Bump No. 1: Lack of Physician Involvement

From the beginning, physicians were resistant to the idea of computerizing their cherished paper charts. There was little involvement of physicians in making critical decisions. Training was another challenge. Nurses are difficult to free from their responsibilities for formal training. The hospital’s all-private physician staff has multiple demands on their time and a strong distaste for classroom-style instruction. Efforts to deliver personalized training to each physician were met with reactions ranging from indifference to outright avoidance. Although the hospital had established that physician training to use the electronic signature application was mandatory, only 15 percent of the active staff received training prior to the system’s go-live date.

Predictably, when the system went live, physicians reacted poorly to what they saw as a worse-than-useless administrative albatross and nefarious government plot. They felt the EHR implementation was an injustice being done to them rather than a clinical tool they had a part in designing.Worse, the physicians as a group dug in their heels and refused to use the new system. The hospital had a hard time understanding their opposition, in part because there was little interaction with them as the system was being implemented. The lesson learned was that redesigning, integrating, and automating clinical processes and workflow is less a technical journey controlled by IT professionals than it is a social and cultural journey that needs strong user champions led by physicians. Decision makers quickly decided that they needed to take a step back and listen to physicians’ complaints rather than continuing to enforce a solution that caused more problems than it solved.

Bump No. 2: Too Much to Learn

With support materials such as instructional mouse pads, posters and pocket guides, most physicians were able to master the basics of signing a medical document online. However, accessing and viewing clinical results online, or placing orders for tests or treatment, proved too complicated for most physicians. They complained of a too-complex user interface, a dearth of user-determined options, and too few available devices. The hospital realized that its expectations of what could be achieved with technology alone were unrealistic. The system’s technical barriers were tolerated by physicians who were experienced, sophisticated computer users, but novice computer users who happened to be good doctors suddenly found the EHR implementation to be a huge impediment to caring for their patients. Those who made enough noise or complained to the right people were able to opt out of using the system altogether, going back to the paper documents with which they were comfortable.

Bump No. 3: Too Much Security

Information is never more secure than when nobody uses it. Physicians were discouraged by a time-consuming and unfriendly security environment. Users had to log in first to the network, then into individual applications.Waiting 45 seconds to get to any useful information poses a big imposition on busy doctors, especially since they typically log in for each patient interaction — perhaps dozens of times per day. Reducing the time and effort to log in to just a few seconds has helped to improve physician acceptance of the clinical information system.

Smoothing the Bumps in the Road

Physician involvement that was lacking in the original implementation — in identifying common concerns and suggesting improvements and customizations to the clinical information systems — is now the responsibility of a standing committee, whose ongoing efforts are coordinated by a soon-to-be-full-time medical informatics specialist. Changes applied to the system as a result of this committee include custom screen views, organization of information flow, and global options settings. Realizing that the EHR implementation as originally conceived was not gaining physician acceptance, the hospital decided to take a more evolutionary approach to adoption of clinical information technology. Physicians are no longer required to use laptops or workstations to access the hospital’s information network. Each physician has been issued a wireless “rounding tool,” a handheld PDA. Custom screen views allow physicians to access and review clinical and financial information, including a patient list, laboratory results, transcribed reports, limited nursing documentation such as vital signs and intake and output data, basic patient demographics, and insurance carrier and policy data. Physicians download the data to their personal devices wirelessly through a traditional infrared synchronization station, a wireless Ethernet connection, or their cellular-based Internet service.

The data they receive are for viewing purposes only — physicians cannot send any information or transmit an interaction back to the computer system. Even though the PDAs lack the ability to store or display large amounts of data, don’t permit two-way communication and lack the broader and more sophisticated range of functions required for CPOE, they represent a first step towards an electronic clinical information system and have proved to be just what the doctors ordered. As physicians get more experience using the PDAs, they gain a better appreciation of the value of electronic clinical information. Already, physicians are requesting training on the core system, and they’re beginning to show wider acceptance of the clinical information tools they were recently so eager to burn and bury.

Design Principles

It’s important to realize that enhancing physician acceptance of this hospital’s EHR implementation had nothing to do with altering the basic information system itself. All the data elements, all the storage and communication processes with which the physicians happily interact on their PDAs are the same as those in the original system they reviled. The difference is in the design of the physician/machine interface — how information traverses the final centimeter between circuit and synapse.

Fundamental Attributes

Certain attributes of an electronic information environment make it fundamentally different from a paper-based information environment. In a computer, input and output are no longer coupled. Though the physician may enter data though one interface, such as a keyboard, the information may be displayed in an entirely different format, layout, sequence and structure. There’s great power in decoupling input from output. Clinicians type lab tests or scan radiology results into the system, but the physician is likely to see that same information in a completely different structure or context.

Decoupling input from output permits interface automation, the ability to customize a data display to present information in a way most useful to a person’s role. For example, one of the early constructive criticisms of this hospital’s interface was that physicians found that the way data were displayed — their sequence and placement on the screen — made it difficult to dictate a discharge summary. Information was awkwardly placed, and physicians had to search around for the data they needed. To solve this complaint, programmers redesigned some of the display screens so that physicians could easily dictate a discharge summary simply by scrolling down a list of data that were more conveniently displayed.

Physicians, clinicians, clerical and administrative staff, and others can access different levels of information in a variety of ways — some intuitive enough to require minimal training, others requiring significant time and effort to learn the system’s more advanced functions and capabilities.

Visual Design Should be Simple, and Reflect the Importance of Displayed Functions

Good interface design makes use of color, font size and other visual differentiators to emphasize the most critical elements of information in a display. For example, abnormal lab values may be highlighted in red, high-priority messages may flash, and completed encounters are often shown in gray. Visual design is also highly dependent on the capabilities of the interface itself. For instance, a good interface for a particular process displayed on a laptop screen would be impractical or impossible to display on a PDA.

Whatever the type of display, effective use of the screen real estate is important. Screen design should be simple and elegant, showing only what is critical to the functional purpose of the current interface page. It’s important to strike the right balance between completeness of data and an overwhelming list of largely unreadable data. Distractions such as superfluous design elements need to be minimized to keep the user focused on the data. Compressing a huge amount of eye-wearying data onto a single screen increases the risk that a physician will miss critical elements.

Help Users Get to the Information They Need as Fast as Possible.

A well-designed user interface displays the most-needed data at the most immediate level. If a physician uses a particular function 80 percent of the time, that physician should be taken to that screen immediately after login. The user interface is what determines whether particular data are deeply embedded, requiring numerous mouse clicks and menus to access them, or whether they are easily accessed with a few clicks or keystrokes.

Documentation by Exception

The use of templates and defaults greatly speeds up interactions with information systems. The ability to use templates in generating clinical notes and defaults in placing orders saves an enormous amount of time, especially for the mediocre typist. A busy doctor can zip through templates and defaults, quickly completing many clerical and clinical transactions. However, the programmer’s good intentions in saving physician’s time and typing can also set them up for trouble if they forget to read what’s in the template. In documenting a medical exam, for instance, it’s easy to zip down the list, checking off items that weren’t actually examined. In placing orders, templates make it easy for doctors to quickly check off items in an order set and end up ordering items that are either unintended or duplicative. Tricks like adding a stopper such as “Is the patient currently breathing?” to a long list of conditions likely to have a checkmark in the “No” column annoys doctors. One suggestion that works is to move around elements of the interface every six months or so. This forces physicians to slow down enough to be more careful in their selections.

Mass Customization

Most information systems are used by multiple constituencies and so need interfaces customized for each of them. Different types of users, and users with different access privileges and levels of computer expertise, must have different ways of interacting with the system:

• User capabilities: novice vs. expert;
• User level: physician vs. R.N.; and
• User focus: primary care M.D. vs. surgeon.

Each has different needs in terms of interface design and accessibility to information.

Familiarity vs. Function

Sometimes, it’s useful to design an interface to resemble what newer users are used to seeing in an older medium. Interfaces that use manila folder tabs or other design elements to resemble a paper chart can help computer novices become more at ease in the electronic medium. However, extensive or prolonged use of interfaces that mimic paper charts can diminish the power of an electronic interface by blocking its ability to use capabilities that have no paper analogue, such as menu-driven (tiered) logic or hyperlinked text, or ignore more efficient structures for data presentation. At each step in implementing a clinical information system, the design of interfaces must be driven by the needs of the clinical processes they support, not the other way around. Maintaining a legacy look and feel to interfaces often subverts this basic design principle.

Conclusion

No clinical information system will achieve the goals expected for it unless the physicians use it. Gaining their acceptance in this case study has been a result of designing the final centimeter — the physician/machine interface — so that the computer is perceived by physicians as an ally, not as an onerous intrusion, to their ability to provide better patient care and to get their work done.

The hospital realizes that reaping the full value of an EHR implementation and its capabilities for computerized order entry, enhanced compliance with evidence-based medical practices and other clinical and financial benefits, requires that physicians eventually transition from the PDAs to a system more like the one originally envisioned.

All physicians are now routinely using PDAs to access and review significant but limited sets of clinical and patient demographic data. For some physicians, the PDAs represent a wholly satisfactory alternative to more comprehensive and powerful electronic interactions. Getting this faction to move on from their PDAs to more sophisticated and interactive tools may prove more difficult than coming to terms with their original resistance.

References

Amit X, Garg, Neill K, Adhikari J, McDonald H, Rosas-Arellano M. Patricia, Deveraux PJ, Beyene J, Sam Justina, Haynes R. Brian. “Effects of Computerized Clinical Decision Support Systems on Practitioner Performance and Patient Outcomes: A Systematic Review.” JAMA. 2005;293:1223-1238.

Wears RL, Berg M. Computer Technology and Clinical Work: “Still Waiting for Godot.” JAMA. 2005;293:1261-1263.

Koppel R, Metlay Joshua P, Cohen Abigail, Abaluch Brian, Localio A. Russell, Kimmel Stephen E, Strom Brian L Role of Computerized “Physician Order Entry Systems in Facilitating Medication Errors.” JAMA. 2005;293:1197-1203.

Note: This paper was first published in the 2005 AHIMA Convention Proceedings