The Malpractices of the Multitudes: the HIT Mission Hostile User Experience, Part 8

More on the origin of this post's title, penned in 1836, below.

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

This post is part 8, and the finale, of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

April 2011 addendum: see what might be considered part 9 at this link.

My college is a member of the iSchool consortium, consisting of schools of information science and technology (notably, not "information technology and science").

The iSchools are interested in the relationship between information, people and technology. This is characterized by a commitment to learning and understanding the role of information in human endeavors. The iSchools take it as given that expertise in all forms of information is required for progress in science, business, education, and culture. This expertise must include understanding of the uses and users of information, as well as information technologies and their applications.

Note the "as well as." Note the primary focus, and that which is secondary. This philosophy parallels that of Medical Informatics well.

This probably sounds like Martian to many in the healthcare and perhaps the broader business IT sector.

One of my colleagues on reviewing this HIT series had this to say:

It's really nice to hear that for once IT professionals have been able to successfully repeat the development lifecycle for healthcare information systems:

• Fail to understand the problem ->

• create a fragmentary and inaccurate requirements definition ->

• design an ambiguous, ignorant and risk-laden user interface ->

• pull all the misguided notions together with baling wire and call it a design->
  

• translate the "design" into an executable form, adding and subtracting design elements at random ->
  

• observe the first output from the system and declare it ready for the healthcare professionals. fini
  

Did I miss anything?

I believe he captured the essense of today's HIT vendor market well.

Here are examples of screen displays of vital patient information, displays that force clinicians to go on wild goose chases and seem designed by true neophytes to the field of information presentation and user interaction design. This is not to single out any one vendor. Many vendor products have deficiencies.

See this display of something as simple (one would think) as blood pressures:

(click to enlarge)

Note the following:

• Diastolic blood pressures in the left column;
• Systolic blood pressures in the roight column;
• An adventure to match them by date;
• No column headers at top.

Which value goes with which? How much energy does it use up to scroll around and connect the two?

This display is so poorly conceived, one wonders why it was included at all in a production system.

There's more. Let's troll for data, shall we?

See the blood oxygen saturation level, circled?

(click to enlarge)

What percentage oxygen was this patient receiving?

It's not there! Where is it?

Scroll down ...

(click to enlarge)

... and down ...

(click to enlarge)

Our answer, at last! Circled. Of course, the corresponding pulse oximetry is now off the screen.

How much attention would it have taken to present the two together?

How much coding would it have taken with today's computers, that execute billions of instructions per second, to dynamically condense the presentation of information, eliminating the absolutely empty cells between the two values?

Similar isses are noted for other biomedically coupled values, such as coumadin dose and blood thinning value (INR).

Screw matching those up, and as my mentor Victor P. Satinsky, MD might have said, your patient's dead.

Speaking about information sparsity, how's this display?

(click to enlarge)

There's one value in the entire screen. What a waste. How much difficulty would it have been to simply present the one row, automatically?

The EHR disperses and fragments vital patient information. How, exactly, is this is supposed to make clinicians more efficient and less error prone?

I am only presenting the easiest to present problems, easiest that is in a static medium such as a blog.

If presented dynamically, we find with some EHR's, for example, that it takes 50 or so mouse clicks across various screens and drop down lists and drop boxes to enter 5 common diagnoses.

It takes selecting from multiple hierarchical lists and buttons across four different screens, multiple times repetitively, to find out how well a patient is eating.

Here is simple advice from J Gen Intern Med 2009; 24(1):21-26.

It is imperative that usability principles are embedded in CPOE design to avoid

• overly complex screens
• poor grouping of like terms
• an inflexible human-computer interface
• mis-use of clinician time

Do the HIT vendors actually read such advice?

I wonder.

Medical Informatics reminds me of dentistry in its early days. B.T. Longbothom, author of the second dentistry book published in the U.S. ("A Treatise on Dentistry", 1802), gave an excellent description in his preface of problems at the time. His observations apply to Medical Informatics in our present age:

The word "dentist" has been so infamously abused by ignorant pretenders, and is in general so indifferently understood, that I cannot forbear giving what I conceive to be its original meaning: viz, the profession of one who undertakes and is capable not only of cleaning, extracting, replacing by transplantation and making artificial teeth, but can also from his knowledge of dentistry, preserve those that remain in good condition, prevent in a very great degree, those that are loose, or those that are in a decayed state, from being further injured, and can guard against the several diseases, to which the teeth, gums and mouth are liable, a knowledge none but those regularly instructed, and who have had a long, and extensive practice, can possibly attain, but which is absolutely necessary, to complete the character of a Surgeon Dentist.

Hardly anyone spoke out.

More than thirty years later, untrained practitioners were as prevalent as ever. One of the leading dentists of the time, Shearjashub Spooner, in his "Guide to Sound Teeth, or, A Popular Treatise on the Teeth" (1836) warned the public of a phenomenon I believe now applies to Medical Informatics and healthcare IT:

One thing is certain, this profession must either rise or sink. If means are not taken to suppress and discountenance the malpractices of the multitude of incompetent persons, who are pressing into it, merely for the sake of its emoluments, it must sink, - for the few competent and well educated men, who are now upholding it, will abandon a disreputable profession, in a country of enterprise like ours, and turn their attention to some other calling more congenial to the feelings of honorable and enlightened men.

I understand that point of view.

And with that, I end this series.

-- SS

Post Title → The Malpractices of the Multitudes: the HIT Mission Hostile User Experience, Part 8

Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 7 of a Series

This post is part 7 of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

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

Want to make a doctor or nurse miserable?

Want to up the odds for error?

Simply force them to review lab results on a screen as sloppily designed and cluttered as this one:

(click to enlarge)

What technical genius programmed this monstrosity? The clutter is enough to impair the best clinicians who have to use such screens day in and day out on their often substantial patient loads.

How is such a screen better than paper?

Does the clinician really need to see subcomponents of panels such as General Chemistry split up all over the place, into sections of columns? Perhaps monolithic columns and horizontal scrolling would be less cognitively taxing? More columns, of course, could be placed in the available screen width if space were not wasted by ... units and Abn's!

Does the clinician really need to see "Abn" as opposed to, say, "A" for abnormals? (At least the abnormals are actually marked in this application, unlike here in "Warning! No warnings!)

Does the clinician need to see units such as mg/dL (milligrams pre deciliter) and mEq/L (milliequivalents per liter) on each and every lab value? Correction - on ANY lab value?

Could not that information be placed - once - in the column or row headers?

(Oh, wait ... as shown here, those headers in some products have a tendency to scroll away, forcing the "track the value with your finger" method of medical error prevention!)

(click to enlarge)

Then there's this, just in from Down Under on clinical decision support, touted as one of the most important benefits of HIT:

Quality of drug interaction alerts in prescribing and dispensing software

Sweidan et al., Medical Journal of Australia 2009; 190 (5): 251-254

Objective: To investigate the quality of drug interaction decision support in selected prescribing and dispensing software systems, and to compare this information with that found in a range of reference sources.

Design and setting: A comparative study, conducted between June 2006 and February 2007, of the support provided for making decisions about 20 major and 20 minor drug interactions in six prescribing and three dispensing software systems used in primary care in Australia. Five electronic reference sources were evaluated for comparison

Results: Six of the nine software systems had a sensitivity rate ≥ 90%, detecting most of the major interactions. Only 3/9 systems had a specificity rate of ≥ 80%, with other systems providing inappropriate or unhelpful alerts for many minor interactions. Only 2/9 systems provided adequate information about clinical effects for more than half the major drug interactions, and 1/9 provided useful management advice for more than half of these. The reference sources had high sensitivity and in general provided more comprehensive clinical information than the software systems.

Conclusions: Drug interaction decision support in commonly used prescribing and dispensing software has significant shortcomings.

More in part 8.

-- SS

Post Title → Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 7 of a Series

Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 6 of a Series

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

This post is part 6 of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

During the Sunday morning talk show "Roundtable" this morning, I saw an IBM ad touting the fact that they'd surpassed the petaflop mark (built computers that can perform one thousand trillion floating point calculations per second).

They touted how such computers will enable weather prediction, medical advances, solutions to social problems, and other cybernetic miracles. (Some of these miracles have been promised since the days of ENIAC in the late 1940's.)

Now, I am indeed amazed by such machines, and realize their value when utilized by competent domain experts overseeing equally competent analysts and programmers, ideally along with HCI (human computer interaction) experts who can help humans interact effectively with such computational high performance.

One would think, though, in a culture where we can perform one thousand trillion calculations per second on large machines, and where consumer machines can perform pretty fast as well that we could do better in the human interface to healthcare IT:

As of 2008, the fastest PC processors (quad-core) perform over 37 GFLOPS (Intel QX9775) [that's 37 billion calculations per second - ed.] GPUs in are considerably more powerful, for example, in the GeForce 8 Series the nVidia 8800 Ultra performs around 576 GFLOPS on 128 processing elements ... There are now graphics cards such as the ATi Radeon HD 4870X2 which can run at over 2.4 TeraFLOPS [2.4 trillion calculations per second - ed.]

Amazing. I used to support applications running on IBM POWER-based supercomputers far slower than 1000 trillion FLOPS for drug discovery at Merck, and chatted with those who used these supercomputers in molecular modeling, critical to drug discovery. Today's computing advances are indeed remarkable just a few years later.

Here is where my disappointment arises.

Health IT seems to be back in the TRS-80 days in terms of its failure to utilize these levels of computing power to create a mission friendly user experience and safer medical care.

HIT user experience: trapped in the TRS-80 era?

Below is how a major healthcare IT system forces a user to do even a simple task, changing the starting date and time for a common medication.

Let's count the steps required for what used to require one step: putting the instrument below to paper.



Keep in mind, health IT is touted as improving the quality of healthcare, reducing errors, and reducing costs.

Step one in the world of HIT (a world, as I said, of MIS-inspired inventory systems, not clinical tools for use by clinicians) involves hunting for, and then clicking "frequency" on a scrolling list of possible "order details", seen on the left of the screen below:

(click to enlarge)

The user then clicks on the "ellipsis button" at upper right, which produces a popup to display the "standard times" for B.I.D. (twice a day) meds:

(click to enlarge)

On the popup subscreen is a list of "standard medication adminstration times" or SMAT's. Here the BID times are shown as 0900 and 2100 (9 AM and 9 PM).

To override these times, more screens, more clicks and more work is needed. The user must click on a "requested start date and time," which has defaulted by programmer edict to the CURRENT data and time. The user is warned in the "User Guide" about how to perform this function as follows-

CAUTION: If you do not change the [default] requested start data and time, the first dose will be scheduled for the current date and time.

The "current time" here being 11:28 AM as on left:

(click to enlarge)

Fantastic. The user must then change the requested start data and time to match the SMAT (standard medication administration time) for the first dose. Say they want the first dose to be given at 2100 (9 PM) tonight.

In the screen below, the user changed this to 6/5/2006 at 2100 (9 PM) to match the SMAT time. The first dose is to be given at 2100 (9 PM) on the current night.

(click to enlarge)

But they're not done yet!

After signing the order, the clinician making the change (often a nurse) will need to click the eMAR (Electronic Medication Administration Record) tab. They must verify something called the "eMAR time frame setting" to be certain that this "time frame" is set for something called the "clinical range." See below:

(click to enlarge)

This act comes with a warning in the instruction manual:

CAUTION: Never limit the eMAR to your shift or to today only. Limiting your view of the eMAR may cause you to inadvertently create medication errors. (!)

Inadvertently create medication errors? Really? Should be easy to fix with machines capable of trillions of calculations per second, no?

No. The user is advised that if the eMAR timeframe is not set to "Clinical Range", all they need do is:

Close the patient's chart, and log out of the health IT application. When you log on next time, the time frame will default to Clinical Range.

Simple, no? Something we all want our doctors and nurses to be doing day in, day out for just this one simple function, no?

Who designed such an interface? What kind of user experience is this, exactly? One designed to make clinical work easier?

Perhap the HIT designers might seek a brain transplant or some other procedure to restore brain function, and then utilize the amazing computational power of modern IT and the advances in biomedical informatics, computational lingustics, parsers (used in building computer program compilers), etc. to allow a user to type in a command with an easily learned syntax such as:

> change Amoxicillin bid 0900 2100 start 06/05/2006

and have the computer popup a verification window that asks:

Are you sure you want to change Amoxicillin to twice daily, 0900 and 2100 (9 AM and 9PM), starting Monday June 5 (Yes/no)?

Or are such undergraduate level computer science feats beyond what's "a good business case" for the HIT vendors, thereby banking on the cognitive diligence of healthcare providers to make up for HIT stupidities?

Are these vendors aware of fifty+ years of computer science, information science, biomedical informatics, HCI and other research? Who, exactly, is creating, testing and approving the clinician user experiences I am illustrating?

Clinicians as technophobes when we're talking about poor IT such as presented in this series? My a**.

In part 7 and on we shall start to see the "peek a boo, wild goose chase, go find your lab data" screens I've mentioned.

-- SS

Post Title → Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 6 of a Series