Are Health IT Designers, Testers and PurchasersTrying to Harm Patients? Part 3 of a Series

(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.)

At the (deliberately) provocatively-titled piece "Are Health IT Designers, Testers and Purchasers Trying to Harm Patients? Part 1" and Part 2, I wrote that I would be presenting mockups showing the EHR deficiencies I am hearing about. These deficiencies in basic human computer interaction, biomedical information science, and presentation of information create a terrible user experience for clinicians.

The title of these posts are deliberately provocative because the stakes of the issues addressed are so high.

These hellish user experiences are causing clinician cognitive overload, distracting and tiring them, and due to violations of fundamental good practices in information display, actually promoting error.

These violations are primarily due to lack of clinician input at design, sluggish vendor correction of reported critical deficits, programmer convenience, contractual gagging of a healthcare organization's ability to share these defects with other users and the public at large, and vendor immunity from liability on the basis of "learned intermediaries" (clinicians) between the defective IT and the patient.

As a medical informaticist who actually studied biomedical information science, user interface design for clinicians and other topics, I am beginning to feel like William Clowes, the famous surgeon of the Tudor period, who inveighed against the skills of many of the practitioners of his own time, characterizing them as:

".. no better than than runagates or vagabonds ... shameless in countenance, lewd in disposition, brutish in judgment and understanding ... tinkers, tooth-drawers, peddlers, ostlers, carters, porters, horse-gelders, horse-leeches, idiots, applesquires, broom-men, bawds, witches, conjurers, soothsayers, sow-gelders, rogues, and rat-catchers!"

That seems to capture the essence of many of the HIT ecosystem players of today. There's nothing new under the sun...

Here is another common EHR defect: the problem list presentation page.

(click to enlarge)

Note that the actual screen is much more dense with other information and smaller fonts than my sketch above, so clinicians have an even harder time than the screen presented here illustrates.

This display gives real meaning to my statement that HIT is designed by MIS (business computing) personnel not as a clinical tool but as an inventory system.

What is wrong with this display? Let me count the ways.

First and foremost, the list is alphabetical. This is very convenient for the programmer, but very inconvenient for the clinician. While just a little bit of clinical and informatics savvy would tend to mandate a problem list ranked or ordered in a priority fashion (e.g., more serious problems first), it's clear that savvy is lacking in an industry that provides a presentation of information clearly unsuited to the purpose of facilitating the practice of medicine!

Clinicians are forced to scan the list and use their own cognitive engine to zero in on the most important problems. Any human being, unfortunately, has a limited supply of "cognitive fuel" during any waking cycle, and when it runs out from overuse, fatigue sets in. Why do EHR designers use up that fuel rather than provide interfaces that are more fuel-efficient?

Second, this list was auto-populated. Problems and diagnoses were not entered manually by the clinician, but through a (perverse) "artificial intelligence" function created by personnel who probably never cared for patients. These items were "extracted" from other parts of the chart. For instance, when an order was placed for Mrs. Jones' glipizide sugar pill and a reason entered, the "diabetes" problem was auto-populated.

That seems nice, except for a wee problem. Others in other parts of the record who enter notes and orders might also indicate diabetes specified by a slightly different term variant, producing the repetitive clutter you see in the screen above. It serves the clinician poorly to see "diabetes" repetitively, and in correct and incorrect variants (type I was an accident).

This auto-population "feature" results in screen clutter and fosters loss of cognitive focus as a clinician reviews multiple patient charts with this same issue.

How can this appear in a production EHR system? Mappings exist in any controlled terminology that permit elimination of such redundancies, which further tax the "cognitive fuel tank" of clinicians. Of course, one has to understand how to utilize these mappings and understand the need to utilize these mappings. The motto of this industry seems to be "let the physicians eat the programmer's dust."

(Also note the presence of useless information: "medication use, long term." What is the purpose of this item in the problem list, if not to simply waste a clinician's time skipping over it?)

Third: note the diagnosis of "atrial fibrillation," an irregularity of the heart rhythm that if not treated properly can result in strokes and death. This is an important piece of information for the clinician to know.

Except, however, when the patient does not have atrial fibrillation. This entry was auto-populated when a nurse ordered a blood clotting test and erroneously entered the reason for the test as "atrial fibrillation" (a common reason, just not the case here) to expedite the order's completion. Voila! Now Mrs. Jones carries this diagnosis, and the next clinician to come along might order her anticoagulated with heparin or coumadin for a history of A. fib, introducing yet more chance of an iatrogenic injury.

And I am told it takes going back to the vendor to have this erroneous entry permanently removed. Sheer idiocy! For instance, if the patient moves to a different unit, is discharged and returns to this hospital, or to an outpatient clinic or another hospital branch with this on the record, the chances of a screwup are not insignificant.

Fourth, and this is the most incredible, physicians are not supposed to manually populate diagnoses (in a future installment I will show the madness that occurs when they try), nor are they in this particular EHR given an opportunity to verify or abort the auto-population selections.

From a medical informatics (and common sense) perspective, that is simply madness. This is cross-occupational piracy. It is computer personnel and hospital executives "stealing" (overriding) physicians' judgment in identifying their patient's problems the way physicians see fit based on their hard-earned expertise.

Do the designers, "certifiers" (this system passed CCHIT certification) and corporate purchasers of such systems have any clue about what they are doing?
Microsoft seems to "get it!" (PDF) How long will it take the rest of the world?

More in Part 4.

It gets worse.

How about massive screen clutter in some screens (wait until I post the meds list!), and data sparsity and disconnectedness of medically related values in other screens? How about screens that force physicians to use the "finger on screen method" of correlating lab value to test type?

-- SS

addendum:

I am told that some of the vendors with products like this sell products to payers that help the payers deny payments on the basis of detecting diagnoses and problems that don't "match" the documentation in ways they deem appropriate. If that is true, they and their corporate customers are truly using physicians as dupes and patsies, forcing them to use ill-designed IT that both impairs their abilities to practice and facilitates payers in denying (or "floating") payments.

EMR-opoly by Al Borges MD. Click to enlarge. Perhaps says it all about the "EMR game."