Tuesday, February 24, 2009

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."

8 comments:

Anonymous said...

Excellent report. Everything that is presented here has been my experience based on my extensive experience as a user of CCHIT (? c-$hit) "certified", yet, inferior CPOE contrivances. Patients were perpetually at risk because doctors are forced to use these defective products with a propensity for absurdity that reaches the patients.

Anechoicism is enforced since health professionals suffer retaliation and threats from hospital administration (often with financial conflicts) for speaking publicly of the injurious defects. This may also be a function of the "non-disparagement clause" sellers force upon the buyers.

How dangerous the care became is witnessed by a reported tripling of the death rate of babies. This experiment must stop and the Office of Human Research Protections (OHRP) must act to protect.

Anonymous said...

Dr Borges,

The EHR-Opoly game is great but you are missing something: a pair of high heeled red pumps.

Did you attend the HIMSS Annual Conference 2007? More specifically the after party?

Have you seen the video of HIMSS CEO Steve Lieber--the one with him dressed in high heeled red pumps.
There is "Certification " here but not of the EHR type...

If you happen to get a copy of the video please make it available as a download and consider your next update of the board game to include "Dorothy's shoes".

Anon

PS: HIMSS Bucks would also be a nice addition

Anonymous said...

Dr. Silverstein:

Our hospital will shortly be dealing with sales pitches from a couple of CPOE vendors. (Some of our management team are convinced that we need to go there at all costs).

I'm not a clinician, I'm the compliance officer and my background is in coding and reimbursement. So I can't speak from first hand experience as to what works on the clinical level. Nevertheless, if it all blows up, I'll lose a lot of evenings and weekends helping to pick up the shrapnel.

With that in mind, can you help me with some pointed questions I should ask, and things I should demand to see?

Anonymous said...

The large group practice my PCP belongs to implemented an EMR within the past year. This product barfs various almost relevant ICD-9 codes onto lab orders and other documents (I've scored "long term use of medication"among others). It also suffers from the "hit enter/Esc to bypass the often-meaningless warning dialog" problem (my pharmacist caught the drug interaction).

The pt gets to make all the phone calls to figure out what's going on, and defers their payment until bills and EOBs square up, the 3rd party payer plays the float, the physician waits longer for payment from both parties.

InformaticsMD said...

With that in mind, can you help me with some pointed questions I should ask, and things I should demand to see?

1. How many formally trained postdoctoral level medical informatics personnel are on staff, and what do they do.
2. What are the worst complaints about the system from clinicians (doctors, RN's etc.) at other hospitals? Can we talk to them?
3. Have you read Ross Koppel's paper on how CPOE can cause new types of error, and are you familiar with Joan Ash's work that reported CPOE's are designed as if for calm, solitary office environments, and what have you done about the findings of such studies in your own products?
4. Are you subcontracting out parts of your software to third party companies, and who are they?
5. What types of user experience testing have you done on your system?
6. Do you have ROI data from other users?

Anonymous said...

In this example of problem lists - you are right! I would fire the programmer if he gave me something like that. (I spent hours showing in real life and diagramming this function) It is also why Medscribbler is not and probably never will be certified - Medscribbler uses both a manual and automatic management of the problem list with a lot more info possible than the example - ie onset, resolved etc Plus sort and flag functions. The trick was to make this easy and quick to do - again all tablet pen designed so it is actually faster than paper.

Jay Habib said...

The author of this blog entry has made some very keen and true observations about software.

You are absolutely right that programmers program for their convenience, not the end-user's.

EMR vendors need to have MDs on their quality control and UI design teams. How many vendors even evaluate and respond to "user feedback" before the ship the product. What I'm trying to say is, at least have a few MDs evaluate the product before you ship it out.

Anonymous said...

Scott - I am taking the time to make sure you understand that *you are on the right track*. Your ideas around the "cognitive fuel tank" are extremely important and unfortunately are under-implemented to such a degree that a clear side effect of EMRs is that they can be deadly. Where the collection and data presentation to the physician and care providers holds the promise of improving care, the extremely poor GUIs in today's horrendously rudimentary EMRs shows us that the current generation of EMRs will not prove to optimize patient care.