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

"You should not have to work around something that is not in the way" - S. Silverstein (me)

(Note: Part 1 of this series 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. 2011 addendums: a post that can be considered part 9 is here, part 10 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.

The issues discussed here and at my academic site on HIT difficulties are not theoretical or speculative. A relative was seriously injured in 2010 as a result of an EMR contributing to a breakdown in clinician communications. They suffered a nearly fatal hemorrhage and major complications due to resultant medication reconciliation failure.

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.

Remarkably (and 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 than of mission critical health IT.

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 a failing grade for an undergrad in a course on HCI (human computer interaction) and certainly in my graduate 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 remains suboptimal.

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 cross-occupational invasion, with doctors' time, professions, and ability to deliver care in essence held hostage.

In future posts in this series I will be presenting mockups showing actual deficiencies I am hearing about (not actual screen shots, unfortunately, since the vendor contracts forbid that on the basis of "intellectual property" protection).

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.

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

More, along with screen mockups created from actual screen shots (the mockups are necessitated by vendor IP protection clauses) appear 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