Mission Hostile Health IT Obstructs Physicians From Ordering Life Saving Drugs In Critical Emergency

"You should not have to work around something that is not in the way" - SS

This post can be considered Part 9 of my multi-part series on the mission hostile user experience presented by commercial healthcare IT.

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, and part 8 is here.

Special K� Red Berries is one of my favorite cereals.




In this context, however, "Special K Red Berries" is a metaphor for cerebral and other hemorrhages caused by health IT getting in the way -- actually obstructing -- physicians ordering emergency medications such as vitamin K given via the fastest route, intravenously.

A cerebral hemorrhage at post-mortem (obviously). Note the "red berry." Similarities in appearance to above cereal bowl ironic.

This EHR system has been deployed for approximately a half decade in a hospital I'll leave unnamed.

It is stunning to me that no clinician has apparently ever complained about the following informatics/relational database integrity "glitch" regarding a not-uncommon clinical scenario, over-anticoagulation (too much blood thinner). If they did complain, however, it would be criminally negligent if the following issue was not corrected.

Atrial fibrillation (Afib) is a heart rhythm disturbance that makes a person prone to throw blood clots from the heart and suffer strokes, and is treated in part by anticoagulant drugs such as heparin and coumadin.

Atrial fibrillation is a disorder found in about 2.2 million Americans. During atrial fibrillation, the heart's two small upper chambers (the atria) quiver instead of beating effectively. Blood isn't pumped completely out of them, so it may pool and clot. If a piece of a blood clot in the atria leaves the heart and becomes lodged in an artery in the brain, a stroke results. About 15 percent of strokes occur in people with atrial fibrillation. The likelihood of developing atrial fibrillation increases with age. Three to five percent of people over 65 have atrial fibrillation

A patient with Afib on coumadin was found to be over-anticoagulated, with a dangerously high INR value, greater than 5. This patient already had a history of a life threatening subdural hematoma (bleeding hemorrhage under the lining of the brain, potentially fatal) a few years prior.

This, the patient was at great risk of catastrophe.

The international normalized ratio (INR) test is a measure of the extrinsic pathway of blood coagulation. It is used to determine the clotting tendency of blood...A high INR level such as INR=5 indicates that there is a high chance of bleeding.

Vitamin K (Aquamephyton) reverses the blood-thinning effects of coumadin. It acts most quickly and is most effective when administered intravenously.

That is, if the computer, now mediating and regulating an increasing amount of healthcare operations, allows the physician to order it that way.

It takes perhaps 3 seconds to write an order such as "aquamephyton 10 mg IV STAT", and a minute or less for the order to be called down to pharmacy by a clerk.

The computer version of the same task worked a bit differently for a very ill patient:

A hospital resident physician, when told to order IV Aquamephyton for urgent administration to this over-anticoagulated patient with atrial fibrillation who had already suffered a subdural hematoma, could only order it subcutaneously due to computer restrictions.

A half-hour of investigation, IT experimentation and phone calls needed to be made to the attending physician and the pharmacy to override that limitation, while the patient lay at critically high risk for another life threatening bleed.

Here are actual de-identified screen shots displaying the mayhem:

Screen 1. Click to enlarge. The physician typed the partial search term "aquam" to locate "aquamephyton", but the order menu stated that "no matching entries found."

Screen 2. Click to enlarge. The physician as a guess then typed "aqua" (instead of "aquam") and the drug and dosing options are listed (but spelled wrong in 2 ways - "aquaAMEPHYTOIN" - which is why "aquam" failed to match anything).

Screenshot 3. Click to enlarge. The physician clicked on the drug to override the fixed options presented in the listing, but the IV route of administration was not available in the drop down box, nor could it be entered in any way.

Screenshot 4. Click to enlarge. Same as #3 but with dose "10 milligrams" filled in. Still no option for IV route on the drop down.

Screenshot 5. Click to enlarge. Continuing the doctor's waste of time and IT misadventure, the doctor typed in "aqu", which leads to the same options. Still no IV route available! Note that there is no automatic reference for the drug offered by the computer.

Screenshot 6. Click to enlarge. After consultation on phone with pharmacist, more time wasted, physician now typed in "phy" (part of the generic name for the drug, i.e., "phytonadione"). BINGO! More options are now available, that are continued on screenshot 7 after scrolling down.

Screenshot 7. Click to enlarge. Med list has been scrolled down. Finally, an IV option is located after a bit of wild goose chasing. ("IVPB" stands for intravenous piggyback). Why were these choices not available under the drug's brand name? It's the same drug!

I won't even go into the computational-linguistics and HCI backwardness of forcing clinicians to go on a distracting 'treasure hunt' through a list of permutations of drug doses and routes, or a menagerie of widgets for parameter specification, for each drug they order, as compared to more advanced methods of command entry. Such methods would have the computer (via the programmers) algorithmically do the bulk of the work. The concept of "parsing" seems alien to health IT vendors, who seem stuck in the paradigms of an earlier data processing era.

Screen shot 8. Physician typed in "vitamin K" and the same options appeared as with "phy." The computer response and administration options to the physician for any of these synonymous drug names should have been exactly the same (even with the "aquaamephytoin" misspelling, once the physician located the drug by luck).

The simple has been turned into the complex, with misspellings, delays and frustration, while a patient at great risk for literal red berries accumulating in his or her head lay in bad, waiting for treatment.

There are parallels between this "glitch" and glitches reported in a competitor's EHR reported by Dr. Jon Patrick in Australia at these links, e.g., regarding faulty data and linkages, user interface problems obstructing clinical work, etc.:

• Analysis of Cerner Problems Defined by ED Directors, http://sydney.edu.au/engineering/it/~hitru/index.php?option=com_content&task=view&id=120&Itemid=116

• A study of an Enterprise Health information System, http://sydney.edu.au/engineering/it/~hitru/index.php?option=com_content&task=view&id=91&Itemid=146

Several questions:

• Is this a configuration/formulary problem local to this organization, or is it a generalized problem with this system originating at the manufacturer? (I've personally reported health IT defects in this software I'd observed in hospitals to FDA's MAUDE database, discovering that the institution itself, whose officials I alerted to the problems, did not. An example of a possible systemic problem is in MAUDE here.)
  

• What other drugs are misspelled, and/or listed under different names with different (and incomplete) ordering options, with no easy and quick override?

• How did these errors get into the system, and why were they not corrected earlier?
  

• Were patients ever injured by this or other similar IT defects within this system?
  

• Is this the technology that will reduce errors and "revolutionize medicine"?
  

• Would you, the reader, want to be that patient waiting for the vitamin K or other critical drug while the doctors fritter away their time and energy on mission hostile computer systems?

Some day you or your family member might be.

-- SS

The Ultimate Workaround To Mission Hostile Health IT: Humans (a.k.a. "Scribes")

"Gentlemen, we can rebuild him. We have the technology. We have the capability to build the world's first bionic doctor. Dr. Data will be that doctor; better worse than he was before. Better, stronger, faster Worse, weaker, slower." -- parody of Oscar Goldman from the 1970's scifi series The Six Million Dollar Man.

"Gentlemen, we can rebuild him."

The EMR is a technology that was supposed to improve clinical medicine (revolutionize it, some say). It was supposed to facilitate clinical medicine. It was not supposed to slow physicians and others down to the point of impairing their ability to practice medicine.

However, the rosy predictions are not proving to be the case. Instead, we have the ultimate workaround to the health IT mission hostile user experience:

Los Angeles Times
September 6, 2010

Harris Meyer

Scribes are doctors' tech support

Melissa Genove has dreamed of becoming a physician since childhood. To help her prepare, she spends as many as 35 hours each week shadowing emergency room doctors at Loma Linda University Medical Center. The 23-year-old listens intently as they examine patients, records their treatment plans in a laptop computer, and follows up on prescriptions, lab tests, consultations with specialists and anything else the doctors order.

Genove is not an intern, or even a medical student. She is the chief medical scribe in the hospital's emergency department � and one of several thousand young people pioneering a new healthcare field.

Scribes are filling a necessary niche as doctors make the wrenching transition from old-fashioned paper charts to 21st century electronic medical records. The computerized system is supposed to make doctors more efficient and ensure better care for patients. Congress has such faith in the value of electronic medical records that it provided as much as $27 billion over 10 years to encourage doctors to use them, and the Centers for Medicare and Medicaid Services will penalize those who don't by cutting their reimbursement rates as much as 5%.

But while the conversion is underway, doctors estimate that their productivity plummets by about 30% as they learn to cope with a complicated new system. [And what clinical IT in 2010 isn't complicated, I ask? - ed.] That's where scribes come in.

This brings real meaning to the observation that "you should not have to work around something that is not in the way."

Just one screen from a Cerner product (from a presentation touting recent addition of a simple database "search" feature that should/could have been present eons ago). Each menu item leads to even more screens, subscreens, menus and pick lists, in labyrinthine fashion. Click to enlarge.

In a domain as complex as medicine, ever-increasing demands for fine grained data on clinical encounters now outstrip the 2010-style human-computer interface's abilities to allow capture of the data without massive interference in the process of medicine itself.

This mismatch is due largely to the limitations of the GUI as the primary user interface (UI) metaphor, especially the widget-centric UI currently in vogue, characterized by massive numbers of screens and GUI widgets, labyrinthine navigation, and forced data entry of artificially and needlessly "atomized" data through interaction with multiple widgets.

CPOE as an example has become a Rube Goldberg contraption (def: "deliberately over-engineered machine that performs a very simple task in a very complex fashion"), the furthest thing from a straightforward "typewriter for orders" as can be.

For instance, a simple order requires interaction with search boxes, multiple drop down lists, scroll bars, check boxes, and other widgets to capture each micro-component of the order, wasting much time compared to writing "Sotalol hydrochloride 120 mg PO BID, first dose now." There are alternatives to "data atomization" and "widget-centricity" in the health IT user interface, apart from simply cleaning up the current interaction disorganization and other weaknesses, but the health IT industry seems largely oblivious to alternatives.

Professor Butts and the Self-Operating Napkin: EMR's have become machines that perform simple tasks in a very complex fashion

Unfortunately, it's difficult to show this complexity using actual EMR images, as most health IT vendors avoid posting screen images and user manuals online, and forbid customers from doing so. They are excessively secretive about their products. Try a Google image search on 'Cerner Millenium' as an example (click here), then compare to an image search on, say, Microsoft Word (click here).

The inappropriate-for-medicine, management information systems (MIS)-derived business model of the healthcare IT vendors and HIT ecosystem also contributes to the, at best, stuck-in-the-1980's health IT user interface. (As an example of these issues, the industry wouldn't even listen to aforementioned UI alternatives even if I served them up on a silver platter, because using the advice would require significant investments on their part to incorporate alternative UI approaches into their products, meaning lower short and medium term profits. Unlike pharma and tangible medical devices, interest in advanced R&D in the health IT industry seems nil. Instead, complacency rules.)

An important question to ponder is whether the dream of the health IT pioneers back in the 1950's and 1960's was too idealistic and indeed unrealistic to begin with. Was it based on "2001, A Space Odyssey"-style overoptimism, and the lack of foreknowledge of how little true progress would be made in the commercial IT market in human computer interaction, artificial intelligence, natural language processing, voice recognition, and other innovations by the 21st century?

Doctors have embraced the scribes as well. "The physicians were spending too much time documenting and not enough time with the patient," said Dr. Robert Steele, chief of Loma Linda's emergency department, which began using scribes in November. "The solution was to take the doctors off the computer, put them at the bedside, and let the scribe do the transcription. It's been a huge success. The physicians love it.

It is not hard to understand why physicians, with their years of training and expertise, would welcome relief from extremely tedious clerical tasks.

Leaders of the three biggest companies providing scribes estimate that about 200 emergency departments in community hospitals and academic medical centers currently use them. More scribes are on the way. Ronald Reagan UCLA Medical Center, Emory University Hospital in Atlanta and Beth Israel Medical Center in New York City said they are exploring the idea. Physicians in other specialties, including urology and family practice, also are starting to adopt scribes.

Still, some physicians question whether college students are equipped to handle the complicated task of charting patients after only two to four months of training. Others wonder why it's necessary to hire additional staff to fill out computerized records that were supposed to be simpler and more efficient than paper.

The key phrase is "were supposed to be simpler and more efficient" than paper. I'd likely be hard-pressed to find robust research supporting that assertion in the scientific literature. I'd be more likely find the origins of this meme in vendor marketing materials.

"It will be interesting to watch whether the need for scribes goes away as the next generation of physicians who grew up with computers and electronic medical records comes in," said Dr. Ann O'Malley, a senior researcher at the Center for Studying Health System Change in Washington, D.C.

This passage implies the bottleneck is those physicians who need to "get used to the IT", whereas a major component of the problem is the health IT user interface itself. Scribes might "go away" if the health IT user experience was vastly improved. The IT needs to become more physician and medicine-friendly.

At Loma Linda [Hospital], Steele said doctors used to spend two minutes with a patient, then take four minutes typing the information into a computer. Now the doctor talks to the patient with the scribe present and summarizes the encounter to the scribe in 30 seconds. While the scribe spends three minutes entering the information into an ever-present laptop, the doctor can spend extra time with the patient.

Afterward, the doctor checks the accuracy of the scribe's chart, makes any necessary additions or corrections, and signs off. Although novice scribes sometimes need the doctor's help in understanding terminology, those with several months' experience usually are spot-on, Steele said.

Again, clerical work is a very poor use of a physician's time. Scribes are a good idea considering 2010's EMR technology, at least from the time/skills perspective.

... [Dr. Michael] Murphy of ScribeAmerica estimates that doctors can see eight additional patients over a 10-hour shift, hiking Medicare revenues alone by $91 an hour.

The companies that develop and sell electronic medical records systems are "in total denial" about how complicated they are for doctors to use, [Dr. David] Strumpf said. "They know these systems need scribes," he said. "They work with us to train our scribes on their systems, but they don't want to be public about it."

(One wonders how much in "denial" the companies are and just who is truly in denial; after all, purchase of these systems just became a governmental priority.)

Here, of course, is the major drawback to scribes: money. Scribes "typically cost $20 to $26 an hour" today, and that number is likely to rise. While the article's contributors maintain that physicians can boost their revenues by "$50 to $60 an hour" using scribes, I wonder if the overall economic impact of the generalized use of tens or hundreds of thousands of EMR scribes would be in the "wrong" direction (i.e., from the payor and government perspective). The billions spent on EMR's were supposed to reduce the costs of healthcare, not increase the expenses associated with it.

I also wonder what could happen when a scribe is not available.

At the University of Virginia Medical Center in Charlottesville, Va., emergency room physicians can complete electronic charts just as fast as scribes, most of whom are pre-med students at UVA. But doctors would rebel if the scribes disappeared, said Dr. Robert Reiser, medical director of the scribe program, which the university runs itself.

Sept. 10 Addendum:

See an interesting financial analysis by Doug Perednia here.

-- SS

FDA MAUDE Database: Patient Outcome - Death

I present another health IT problem case from the FDA's voluntary MAUDE (Manufacturer and User Facility Device Experience) database below.

From FDA's description of MAUDE:

• MAUDE data represents reports of adverse events involving medical devices. The data consists of voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996. MAUDE may not include reports made according to exemptions, variances, or alternative reporting requirements granted under 21 CFR 803.19.
• The on-line search allows you to search CDRH database information on medical devices which may have malfunctioned or caused a death or serious injury. MAUDE is scheduled to be updated monthly and the search page reflects the date of the most recent update. FDA seeks to include all reports received prior to the update. However, the inclusion of some reports may be delayed by technical or clerical difficulties.
• MAUDE data is not intended to be used either to evaluate rates of adverse events or to compare adverse event occurrence rates across devices. Please be aware that reports regarding device trade names may have been submitted under different manufacturer names. Searches only retrieve records that contain the search term(s) provided by the requester.

I somehow missed the following case when I wrote the Oct. 2009 post 'Our Policy Is To Always Have Unabashed Faith In The Computer ... Except When It Screws Up, And Then It's The Doctor's Fault' but I have added it there as well:

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/detail.cfm?mdrfoi__id=1656460
CERNER MILLENIUM POWERCHART CPOE
Event Date 11/19/2006
Event Type: Death
Patient Outcome: Death

The medication review screen of the subject device does not specify the exact dose in milligrams of combination medications. For example, narcotics are combined with tylenol in at least two strengths. Liquid narcotic tylenol-oxycodone combination is reported in ml, not mg. The exact dose of tylenol is not specified and requires knowledge of the combination medication dose in the volume specified.

Certain fields of the grid do not specify the volume, but rather state "date/time" requiring another click or pop up screen. The immediate knowledge of tylenol dosage in mg is directly related to understanding and preventing excessive doses. In the subject, 10 ml of acetaminophen-oxycodone is indicated as having been given 3 times over 4 hours. That means that 1950 mg of tylenol was administered in 4 hours while the patient was in a state of starvation and receiving other medication that increase the effects of tylenol.

This dose would equate to 11,700 mg of tylenol over 24 hours, nearly 3 times the maximum daily dose in otherwise health people. In the ensuing days, the patient developed acute renal failure, presumably acute tubular necrosis, and died. In the absence of other etiology, the excess tylenol was the culprit. This was not considered as etiology ante-mortem. The counterintuitive screen impaired the professionals. The pharmacist did not recognize and stop the medication, the nurses administered it, and the excessive dose, clinically meaninglessly listed as a volume of 10 ml -given 3 times in 4 hours- of acetaminophen-oxycodone, was missed by the physicians. Adverse events have been ascribed to "user error" by vendors.

The device offers a potent propensity to life endangering oversights. There are other screens on this device which present information that interfere with clinically useful visualization of data. [Who designed these screens, I ask? Clinicians, or business IT personnel used to designing inventory systems for widget control? - ed.] The data does not flow to the professionals. It is not represented in a meaningfully useful manner.

The professionals need to hunt for it. As such, the user unfriendly screens [see this link on mission hostile HIT - ed.] impair safe medical care consistent with the impediment to expedient professional understanding of what, exactly, is the dose of medication and how much was administered to the patient. This sentinel case of death is directly attributed to user unfriendly screens on this device.

How many cases like this, as well as "near misses" related to health IT go unreported, nationwide and worldwide?

As in my paper "Remediating an Unintended Consequence of Healthcare IT: A Dearth of Data on Unintended Consequences of Healthcare IT", nobody really knows; these devices are unregulated with no requirements for reporting.

However, let's roll it out nationally anyway, because HIT will deterministically "revolutionize" medicine. Just ignore those spoil-the-party, man-behind-the-curtain prattle from writers like these.

We can safely ignore all contrarian research and literature, of course, as we all know HIT will revolutionize medicine from the definitive certainty of HHS in "The 'Meaningful Use' Regulation for Electronic Health Records", NEJM, Blumenthal and Tavenner (10.1056/NEJMp1006114, July 13, 2010):

The widespread use of electronic health records (EHRs) in the United States is inevitable. EHRs will improve caregivers� decisions and patients� outcomes. Once patients experience the benefits of this technology, they will demand nothing less from their providers. Hundreds of thousands of physicians have already seen these benefits in their clinical practice.

[Except for those who haven't - ed.]

And our government's called BP Energy Company cavalier?

I offer no additional comments.

-- SS

Did EPIC CEO Judy Faulkner of Epic declare that �healthcare IT usability would be part of certification over her dead body?'

At the HisTALK blog 5/31/10 update, a site with thousands of readers involved in all aspects of health IT, the following anonymous (at this point) report appeared:

From Tabula Rosa: �Re: EMR usability. At one of the ONC Policy Committee meetings, [founder and CEO] Judy Faulkner of Epic supposedly declared that �usability would be part of certification over her dead body.� I wonder if she has similar sentiments about making software accessible to people with disabilities?� Unverified. This inspired my new poll question � keep reading below.

Epic Systems Corporation is one of the largest health IT vendors in the U.S.

If this report is true, it would have very, very serious implications towards the healthcare IT industry's attitudes about the usability - and ultimately the safety - of its products.

The essential nature of usability and the relationship to safety is not an issue for debate - period. It was settled long ago in relation not only to IT, but also to devices and machinery that use IT. For instance, see the mid 1980's wisdom written for the U.S. Air Force on user interfaces at my eight part series on mission hostile health IT user experiences at http://tinyurl.com/hostileuserexper. Microsoft and other responsible IT vendors spend billions on usability research.

I think it incumbent of the U.S. Office of the National Coordinator for Health IT, and its leader Dr. David Blumenthal, to confirm or deny that such a statement was made, on or off-record, at an ONC policy committee meeting, and if it was made, its exact context.

If it was made, it would raise the following questions:

• Would its utterer be saying this out of concern that their products have usability deficiencies that competitors do not, and that are not correctable in a short time frame?
• How much concern would such a statement indicate for the complex jobs of physicians, nurses and other clinicians whose safe conduct of their medical obligations depends on health IT?
• How much concern would such a statement imply towards the injured and dead bodies of patients affected by health IT of deficient usability?
• Since the CEO sets the tone for their company and has the ultimate responsibility for its conduct (and its Board of Directors as well), would such a statement reflect willful negligence and perhaps criminal conduct?

The last question is pertinent, for if, say, the CEO of Boeing were to relate that "usability of the control systems of its aircraft would be an FAA certification requirement over his or her dead body", or the CEO of oil drilling companies said same about their instrumentation that helps avoid underwater blowouts, I believe it would rise to the level of criminally negligent conduct.

This is all the more pertinent to me, as my relative was just seriously injured by a medication error that appears to have started with the med list in an EMR.

I am seriously wondering, in fact, if the average hospital has the gravitas and political and technologic maturity to truly implement health IT so that the technology is uniformly beneficial, instead of spontaneously harmful, to meet the needs of the grandiose plans for national health IT.

The lack of seriousness, petty political fights, and technological dyscompetence and incompetence I have noted in my 20 years in this field do not seem surmountable in any time frame I consider "soon."

Here seems to be the health IT industry and hospital MIS department view of healthcare IT, as some sort of game to be played for profit, power and political advantage:




-- SS

Why The Apple iPad Will Not Revolutionize, Change the Game, Transform or Create New Paradigms in Medicine Anytime Soon

The announcement of the Apple iPad has been accompanied by the usual irrationally exuberant, buzzword-laden statements and bellicose grandiosity from the IT punditry about how it will "revolutionize" or "transform" medicine.

However, this will not occur anytime soon, for in medicine, the device may help solve a portability and visibility problem (compared to PDA's), but it will not solve this problem: the mission hostile user experience.

The solution to that problem will require significant human magic.

-- SS