Are Health IT Designers, Testers and Purchasers Trying to Harm Patients? Part 1 of a Series

(Part 1 is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, part 7 is here, and part 8 is here.)

In effect through superciliousness and complacency, they just might be, along with the people who approve EMR's, CPOE's and other clinical IT for sale, as well as those who actually purchase this IT for healthcare organizations.

The title of this post is deliberately provocative because the stakes of the issues addressed are so high, not to mention a personal motivation. My father died as a result of informational errors at a major hospital that could have been prevented with an effective EHR. These posts are dedicated to his memory.

Clearly more "inclusive" approaches by clinicians towards addressing these issues have not succeeded.

I've recently been conversing with a number of correspondents at major healthcare systems about just how bad health IT is. EMR's and CPOE's that confound and intimidate and look as if designed by computing amateurs are the topic of discussion.

Here is a simple first principle:

Clinical IT should under no circumstances present a mission hostile user experience.

I have seen offenses such as clinically important, related data elements scattered far and wide making physicians and nurses go on wild goose chases or "click-o-rrhea" (a term coined by an MD HIT user who wishes to remain anonymous) to relate them; diagnosis lists that place rare diagnoses near the top and common ones a hundred items below; boxes that hide part of diagnostic terms leading to incorrect selections, and many other violations of even the most basic principles of creating a good user experience and of good information science.

Who would design HIT that forces clinicians to go on wild goose chases to find important data? (Au contraire, this graylag and her Canada goose and Mute Swan friends chase me for treats of bread and grains, see photos here. HIT designers should only treat users as well.)

Ironically, we as a culture devote far more time and energy debating the user experience presented by Windows XP/Vista/7, vs. Mac OS X, vs. various Linux flavors, and of PDA's, MP3 players and cellphones!

The EHR user experience? Bluntly stated, "let the doctors eat cake" seems to be the Marie Antoinette-like corporate attitude.

What I have seen in production systems actually in use would have earned an "F" for even an undergrad in a course on HCI (human computer interaction) and certainly in my healthcare informatics courses.

Here is mid 1980's wisdom written for the U.S. Air Force on user interfaces:

SIGNIFICANCE OF THE USER INTERFACE

The design of user interface software is not only expensive and time-consuming, but it is also critical for effective system performance. To be sure, users can sometimes compensate for poor design with extra effort. Probably no single user interface design flaw, in itself, will cause system failure. But there is a limit to how well users can adapt to a poorly designed interface. As one deficiency is added to another, the cumulative negative effects may eventually result in system failure, poor performance, and/or user complaints.

Outright system failure can be seen in systems that are underused, where use is optional, or are abandoned entirely. There may be retention of (or reversion to) manual data handling procedures, with little use of automated capabilities. When a system fails in this way, the result is disrupted operation, wasted time, effort and money, and failure to achieve the potential benefits of automated information handling.

In a constrained environment, such as that of many military and commercial information systems, users may have little choice but to make do with whatever interface design is provided. There the symptoms of poor user interface design may appear in degraded performance. Frequent and/or serious errors in data handling may result from confusing user interface design [in medicine, this often translates to reduced safety and reduced care quality - ed.] Tedious user procedures may slow data processing, resulting in longer queues at the checkout counter, the teller's window, the visa office, the truck dock, [the hospital floor or doctor's office - ed.] or any other workplace where the potential benefits of computer support are outweighed by an unintended increase in human effort.

In situations where degradation in system performance is not so easily measured, symptoms of poor user interface design may appear as user complaints. The system may be described as hard to learn, or clumsy, tiring and slow to use [often heard in medicine, but too often blamed on "physician resistance" - ed.] The users' view of a system is conditioned chiefly by experience with its interface. If the user interface is unsatisfactory, the users' view of the system will be negative regardless of any niceties of internal computer processing.

A convincing demonstration of design improvement has been reported by Keister and Gallaway (1983). Those authors describe a data entry application in which relatively simple improvements to user interface software -- including selection and formatting of displayed data, consistency in wording and procedures, on-line user guidance, explicit error messages, re-entry rather than overtyping for data change, elimination of abbreviations, etc. -- resulted in significantly improved system performance. Data entry was accomplished 25 percent faster, and with 25 percent fewer errors.

Two decades later, healthcare IT design seems to be ruled by Mr. Magoo.

In 2009 many physicians using healthcare IT applications have all but "given up" on trying to get major user experience deficiencies corrected and just do as best they can, hoping to avoid burnout and malpractice suits. Physician learned helplessness incarnate.

The products I have been hearing about (which, incidentally, the users believe are "CCHIT certified") are not just bad, but spectacularly bad. IT has been trampling over medicine, a disgraceful cross-occupational invasion, with doctors' time, professions, and ability to deliver care held hostage.

In future posts in this series I will be presenting mockups showing the deficiencies I am hearing about (not actual screen shots, since the vendor contracts forbid that on the basis of "intellectual property" protection - ironically, even information technology not worthy of an undergrad can be fiercely protected as IP).

These observations may also help better explain why many organizations seem to choose an EMR or other clinical IT first, and then seek to hire medical informatics expertise later. They need a willing physician with informatics credentials to help hide the sour taste of deficient IT their fellow clinicians are asked (or mandated) to consume.

Nonclinicians may be startled by what their caregivers and the care they provide is being subjected to, without patient consent.

More, along with screen mockups, in Part 2.

The series is unique to date as far as I can tell.

(Note: part 2 is here and part 3 is here.)

--- SS