A Few Additional Comments on the GE Radiation Debacle

Roy Poses beat me to posting about the General Electric CT over-irradiation debacle (GE: Don't Know Much About Radiation Safety, Don't Know Much About Physics).

I am going to add two points:

Point 1:

The National Research Council in its 2009 report on health IT warned that "current approaches to healthcare IT are insufficient", and one of the major caveats was that:

... greater emphasis should be placed on information technology that provides health care workers and patients with cognitive support, such as assistance in decision-making and problem-solving.

In fact the lack of cognitive support for clinicians was one of the report's major themes.

"Cognitive support" by definition means producing devices (whether physical or virtual) that are intended for busy clinical settings where situations often resemble a madhouse - not calm, solitary office environments (borrowing from Joan Ash's findings on CPOE flaws):

"Many information systems simply don't reflect the health care professional's hectic work environment with its all too frequent interruptions from phone calls, pages, colleagues and patients. Instead these are designed for people who work in calm and solitary environments. This design disconnect is the source of both types of silent errors …Some patient care information systems require data entry that is so elaborate that time spent recording patient data is significantly greater than it was with its paper predecessors," the authors wrote. "What is worse, on several occasions during our studies, overly structured data entry led to a loss of cognitive focus by the clinician."

It does not mean, as reported on July 31, 2010 in the New York Times, that designers and vendors of these medical devices should take the stance of blaming the user:

A GE spokesman, Arvind Gopalratnam, said the way scanners were programmed was “determined by the user and not the manufacturer.” GE, he added, has no record of Glendale seeking its help setting up the new procedure in 2009.

... GE says the hospitals should have known how to safely use the automatic feature. Besides, GE said, the feature had “limited utility” for a perfusion scan because the test targets one specific area of the brain, rather than body parts of varying thickness. In addition, experts say high-clarity images are not needed to track blood flow in the brain.

GE further faulted hospital technologists for failing to notice dosing levels on their treatment screens.

But representatives of both hospitals said GE trainers never fully explained the automatic feature.

Imagine the reaction if Boeing blamed pilots for collisions if those pilots, busy with other matters, were only alerted to an impending collision via a range reading on their cluttered instrument panel - rather than a LOUD AUDIBLE ALARM - such as WARNING, WARNING, COLLISION IMMINENT.

Point 2:

What's really missing here was attention to cognitive support for busy clinicians. This, of course, requires proper senior management - senior management with the appropriate expertise.

Proper senior management then controls talent management down the chain of an organization. If the leaders "don't know nothing 'bout trigonometry", they will be less likely to put mathematicians in appropriate leadership roles.

If management doesn't understand Medical Informatics, they will be less likely to put informaticists into leadership roles as well. One major focus of Medical Informatics is cognitive support of busy clinicians in their all too real-world environments.

Why might the latter point be relevant at GE?

In 1999 after working for a competitor of GE, Comdisco Healthcare Group, who among other business aspects reconditioned and resold capital equipment such as CT scanners, I wrote this in an essay on "what medical informatics is not":

... I've noted a number of large vendors and even national medical organizations whose so-called "Medical Informatics Directors" had neither clinical backgrounds nor training in medical informatics (nor in information science of any kind). MIS managers, social workers, and clinicians with no more experience than some tinkering with a home Macintosh can be found as "Directors of Medical Informatics" in the (unfortunately) unregulated healthcare IT industry.

Sometimes the term is used as a sales slogan. General Electric displayed a huge banner over their booth proclaiming themselves "the world leader in Radiology Informatics" at the 1999 Radiological Society of North America (RSNA) conference in Chicago. Unfortunately, nobody present, including sales, management, and engineering representatives, could explain to me what that term meant. They actually said they did not know. I had only identified myself as a physician at that point, not as a medical informatics professional, and expressed incredulity on nobody being able to explain the banner to me. Under pressure, one GE engineer offered the statement "I think it has something to do with computers attached to our x-ray machines."

It's now 2010. It seems GE still may not know what Medical Informatics is.

Handing busy clinical end users a revolver with a single bullet in the chamber, and asking them to play Russian Roulette under busy circumstances with a warning to "check the chamber carefully each time before you pull the trigger", is simply unacceptable for computerized medical device design.

-- SS

A Few Additional Comments on the GE Radiation Debacle

Roy Poses beat me to posting about the General Electric CT over-irradiation debacle (GE: Don't Know Much About Radiation Safety, Don't Know Much About Physics).

I am going to add two points:

Point 1:

The National Research Council in its 2009 report on health IT warned that "current approaches to healthcare IT are insufficient", and one of the major caveats was that:

... greater emphasis should be placed on information technology that provides health care workers and patients with cognitive support, such as assistance in decision-making and problem-solving.

In fact the lack of cognitive support for clinicians was one of the report's major themes.

"Cognitive support" by definition means producing devices (whether physical or virtual) that are intended for busy clinical settings where situations often resemble a madhouse - not calm, solitary office environments (borrowing from Joan Ash's findings on CPOE flaws):

"Many information systems simply don't reflect the health care professional's hectic work environment with its all too frequent interruptions from phone calls, pages, colleagues and patients. Instead these are designed for people who work in calm and solitary environments. This design disconnect is the source of both types of silent errors …Some patient care information systems require data entry that is so elaborate that time spent recording patient data is significantly greater than it was with its paper predecessors," the authors wrote. "What is worse, on several occasions during our studies, overly structured data entry led to a loss of cognitive focus by the clinician."

It does not mean, as reported on July 31, 2010 in the New York Times, that designers and vendors of these medical devices should take the stance of blaming the user:

A GE spokesman, Arvind Gopalratnam, said the way scanners were programmed was “determined by the user and not the manufacturer.” GE, he added, has no record of Glendale seeking its help setting up the new procedure in 2009.

... GE says the hospitals should have known how to safely use the automatic feature. Besides, GE said, the feature had “limited utility” for a perfusion scan because the test targets one specific area of the brain, rather than body parts of varying thickness. In addition, experts say high-clarity images are not needed to track blood flow in the brain.

GE further faulted hospital technologists for failing to notice dosing levels on their treatment screens.

But representatives of both hospitals said GE trainers never fully explained the automatic feature.

Imagine the reaction if Boeing blamed pilots for collisions if those pilots, busy with other matters, were only alerted to an impending collision via a range reading on their cluttered instrument panel - rather than a LOUD AUDIBLE ALARM - such as WARNING, WARNING, COLLISION IMMINENT.

Point 2:

What's really missing here was attention to cognitive support for busy clinicians. This, of course, requires proper senior management - senior management with the appropriate expertise.

Proper senior management then controls talent management down the chain of an organization. If the leaders "don't know nothing 'bout trigonometry", they will be less likely to put mathematicians in appropriate leadership roles.

If management doesn't understand Medical Informatics, they will be less likely to put informaticists into leadership roles as well. One major focus of Medical Informatics is cognitive support of busy clinicians in their all too real-world environments.

Why might the latter point be relevant at GE?

In 1999 after working for a competitor of GE, Comdisco Healthcare Group, who among other business aspects reconditioned and resold capital equipment such as CT scanners, I wrote this in an essay on "what medical informatics is not":

... I've noted a number of large vendors and even national medical organizations whose so-called "Medical Informatics Directors" had neither clinical backgrounds nor training in medical informatics (nor in information science of any kind). MIS managers, social workers, and clinicians with no more experience than some tinkering with a home Macintosh can be found as "Directors of Medical Informatics" in the (unfortunately) unregulated healthcare IT industry.

Sometimes the term is used as a sales slogan. General Electric displayed a huge banner over their booth proclaiming themselves "the world leader in Radiology Informatics" at the 1999 Radiological Society of North America (RSNA) conference in Chicago. Unfortunately, nobody present, including sales, management, and engineering representatives, could explain to me what that term meant. They actually said they did not know. I had only identified myself as a physician at that point, not as a medical informatics professional, and expressed incredulity on nobody being able to explain the banner to me. Under pressure, one GE engineer offered the statement "I think it has something to do with computers attached to our x-ray machines."

It's now 2010. It seems GE still may not know what Medical Informatics is.

Handing busy clinical end users a revolver with a single bullet in the chamber, and asking them to play Russian Roulette under busy circumstances with a warning to "check the chamber carefully each time before you pull the trigger", is simply unacceptable for computerized medical device design.

-- SS

Medical Informatics, Pharma, Health IT, and Golden Advice That Sits Sadly Unused

In recent correspondences with colleagues I was reminded of a letter I wrote seven years ago that was published in Bio-IT World, a journal about biomedicine focusing mainly on pharma, bioinformatics and related fields.

As the sole formally-trained Medical Informatics specialist at Merck, I wrote:

Medical Informatics MIA [Missing in Action - ed.]
Bio-IT World
August 13, 2002

Dear Bio-IT World:

I enjoyed reading the article "Informatics Moves to the Head of the Class" (June Bio·IT World). Thank you for spotlighting the National Library of Medicine (NLM) training programs in medical informatics and bioinformatics, of which I am a graduate (Yale, 1994).

Bioinformatics appears to receive more media attention and offer more status, career opportunities, and compensation than the less-prestigious medical informatics.

This disparity, however, may impede the development of next-generation medicines. Bioinformatics discoveries may be more likely to result in new medicines, for example via pharmacogenomics, when they are coupled with large-scale, concurrent, ongoing clinical data collection. At the same time, applied medical informatics, as a distinct specialty, is essential to the success of extensive clinical data collection efforts, especially at the point of care.

Hospital and provider MIS personnel are best equipped for implementing business-oriented IT, not clinical IT. Implementing clinical IT in patient-care settings constitutes one of the core competencies of applied medical informaticists.

Informatics specialists with a bioinformatics focus — even those coming from the new joint programs — usually are not proficient in hospital business and management issues that impede adoption of clinical IT in patient care settings. Such organizational and territorial issues are in no small way responsible for the low utilization of clinical IT in patient care settings.

It will be important for medical informaticists focused in the clinical domain and bioinformaticists specializing in the molecular domain to collaborate with other specialists in order to best integrate clinical and genomic data.

Further information on these issues can be found in the book Organizational Aspects of Health Informatics: Managing Technological Change, by Nancy M. Lorenzi and Robert T. Riley (Springer-Verlag, 1995). Various publications from the medical informatics community, such as the American Medical Informatics Association (www.amia.org) and the International Medical Informatics Association (www.imia.org), are also useful.

Scot Silverstein, MD
Director, Published Information Resources & The Merck Index
Merck Research Laboratories

I was also responsible for the entry of the term "Medical Informatics" into the controlled vocabulary pool used for various purposes at Merck.

As far as I can tell, the Medical Informatics talent gap still exists in all major pharmas despite writings on the topic from colleagues as well as myself. With the present turmoil including declining pipelines, mergers and mass layoffs pending in many large pharmas, and even despite Medical Informatics on a fast path to being declared a full medical subspecialty, it is likely this gap will persist for years longer. This is a shame. The field offers insights that can help R&D substantially, and I speak from direct experience from my time in that domain.

I am reminded via all this of another industry that seems to hurt itself via ignoring the advice of Medical Informatics professionals, the health IT industry. Healthcare IT is actually the core competence of Medical Informatics professionals, but those people are under-represented in the higher ranks of the health IT industry as well. Many job postings seek such people, but for lower level roles (as I've posted here in the past), and/or conflate formal training with informal experience and with those who qualify for the title of Medical Informaticist like I qualify (being an amateur radio licensee, extra class) as a professional RF engineer.

The irony is this: the wisdom of the Medical Informatics field on health IT goes back not years, but decades. It is advice that could have made the vendors much higher margins, allowed them to produce better products, avoid the government regulation that is now nearly inevitable (in some EU countries, clinical IT has already been determined to be a medical device requiring regulation), and in many cases, enabled corporate longevity.

Yet the teachings and accumulated wisdom of the field were, and largely still are, ignored, making books such as the new "H.I.T. or Miss: Lessons Learned from Health Information Technology Implementations" necessary even in 2009.

Here is just a small sampling of that wisdom:

Dr. Donald A. B. Lindberg (now Director of the U.S. National Library of Medicine at NIH), 1969:
"Computer engineering experts per se have virtually no idea of the real problems of medical or even hospital practice, and furthermore have consistently underestimated the complexity of the problems…in no cases can [building appropriate clinical information systems] be done, simply because they have not been defined with the physician as the continuing major contributor and user of the information."


Dr. Octo Barnett's [Harvard] health IT Ten Commandments, 1970:
1. Thou shall know what you want to do
2. Thou shall construct modular systems - given chaotic nature of hospitals
3. Thou shall build a computer system that can evolve in a graceful fashion
4. Thou shall build a system that allows easy and rapid programming development and modification
5. Thou shall build a system that has consistently rapid response time and is easy for the non-computernik to use
6. Thou shall have duplicate hardware systems
7. Thou shall build and implement your system in a joint effort with real users in a real situation with real problems
8. Thou shall be concerned with realities of the cost and projected benefit of the computer system
9. Innovation in computer technology is not enough; there must be a commitment to the potentials of radical change in other aspects of healthcare delivery, particularly those having to do with organization and manpower utilization
10. Be optimistic about the future, supportive of good work that is being done, passionate in your commitment, but always guided by a fundamental skepticism.

[Dr. Barnett played a key role in the 2009 National Research Council report about current approaches to health IT being inadequate, Press Release at http://www8.nationalacademies.org/onpinews/newsitem.aspx?RecordID=12572, and full report "COMPUTATIONAL TECHNOLOGY FOR EFFECTIVE HEALTH CARE: IMMEDIATE STEPS AND STRATEGIC DIRECTIONS. - ed.]


Dr. Morris Collen's Five Rules, 1972
Most common causes of health IT failure:

• Suboptimal mix of medical and computer specialists … resulting in communications difficulties and in the computer staff underestimating the vast medical needs
• Gross underestimation of the large amounts of money needed
• Suboptimal systems approach with serious incompatibilities between modules
• Unacceptable terminals
• Inadequate management organization and poor judgment
  

Dr. R. Friedman, Reasons for slow spread of EMR, 1977:

• Poor engineering and unreliability
• Physicians not provided with computer-based applications that exceeded their own capability!
• Inability to prove a positive effect on patient care
• Difficulty transferring one application from one institution to another
  

(All taken from Collen's "A history of Medical Informatics in the United States, 1950-1990".)

I might add that the PC did not even exist in 1977, unless you consider the Altair and Heathkit H8 "personal computers."

Four-decades-old wisdom like this, and much more, sits out there in the ether and in the Medical Informatics field's professionals like a pot of gold, but is apparently considered as valuable as lead by the HIT - and pharma - industries. I find this amazing - and a pity.

-- SS

"A cadre of people who understand the science"

Here is a fascinating, spot-on exchange regarding biomedical information science between Bill Moyers on PBS and the new President of Dartmouth College Dr. Jim Yong Kim (link). My comments in [red italics]:

DR. JIM YONG KIM: My own particular take on it is that I think for many, many years, we've been working under the fantasy that if we come up with new drugs and new treatments, we're done. 

The rest of the system will take care of itself. In my view, the rocket science in health and health care is how we deliver it. And unfortunately, there's not a single medical school that I know of that actually teaches the delivery of health care as one of the essential sciences. 

In other words, what we've learned about organizations is that it is very difficult to get a complex organization, a group of people, to work consistently toward a goal. In the business world, if you don't do it well, the market gets rid of you. You go out of business. But many hospitals executing very poorly persist for a very, very long time. So my own view of it is that we have to rethink fundamentally the kind of research we do and the kind of people we educate, so that they'll think about the complexity of delivery as a topic that we can take on and study and learn about as a science. [And possess a broad and deep enough background to understand these issues at very fine-grained levels, which in my opinion includes a rigorous scientific background to start with - ed.]

BILL MOYERS: What do you mean, complexity of delivery?

DR. JIM YONG KIM: Well, just think about a single patient. So a patient comes into the hospital. There's a judgment made the minute that patient walks into the emergency room about how sick that person is. And then there are relays of information from the triage nurse to the physician, from the physician to the other physician, who comes on the shift. 

From them to the ward team, that takes over that patient. There's so many just transfers of information. You know, we haven't looked at that transfer of information the way that, for example, Southwest Airlines has. Apparently they do it better than any other company in the world. [I would add that the nature of such transfers and the complexity of the information itself is far simpler in the Airline business than in medicine, so this is not the best analogy - ed.]

BILL MOYERS: Computers?

DR. JIM YONG KIM: No, they have taken seriously the human science of how you transfer simple information from one person to the next. [Note how Dr. Yong Kim wisely dismisses computers as the solution, in favor of people. He does not suffer the syndrome of inappropriate overconfidence in computers - ed.] And in medical school, and in the hospitals that I've worked in, we've done it ad hoc. Sometimes we do it well. Sometimes we don't do it well. But what we know is that transfer of information is critical. Now to me, again, that's the rocket science. That's the human rocket science of how you make health care systems work well 

What we need now is a whole new cadre of people who understand the science, who really are committed to patient care. But then also think about how to make those human systems work effectively. We've been calling it, aspirationally, the science of health care delivery. And we do it at Dartmouth. 

30 years ago, one of our great faculty members, Jack Wennberg, started asking a pretty simple question. Why is there variation, for example, in the number of children who get their tonsils taken out, between one county in Vermont versus another? 'Cause one of his children was in school at one place. Another of his children were in the school in another place. 

And in one place, almost everyone had their tonsils out. And in another place, almost no one did. And of course, he found that there happened to be a doctor there who liked to take tonsils out and benefited from it. And he kept asking this question, you know, outcome variation. He called it the evaluative clinical sciences. And I think that's really the forerunner to what we're talking about in terms of the science of--

BILL MOYERS: Fancy--

DR. JIM YONG KIM: --health care delivery.

I can add that part of that "cadre of people who understand the [information transfer] science" exists, in the form of Medical Informatics specialists (e.g., as produced by these organizations and many others in the U.S. and worldwide). Understanding the complexities of information transfer also calls for understanding the clinical environment and, in my view, the biomedical science as well.

However, you might never know this via reading statements from some of the non-clinical HIT leaders such as "computers enable complexity" [as opposed to well-trained and experienced medical experts - ed.]

It is indeed unfortunate that most hospital ads seeking Medical Informatics expertise are for "Director level" positions with little control of resources, i.e., they are "Director of Nothing" roles, diluting the contributions of such experts in the highly politicized and territorial environment of a hospital IT department.

Unfortunately, most in hospital IT today are just repackaged business computing personnel of a management information systems (MIS) background whose lack of knowledge of these topics or cavalier attitudes about them has actually harmed the progression of health IT as a practical tool, as I've profusely documented on this blog (e.g., here) and at my educational HIT site here.

An example of just how difficult the "rocket science" of information transfer can be is this, from a psychiatrist:

I work on an acute psychiatric inpatient unit. We see each patient on rounds each day, write a note in the chart each day and bill each day. However, the nature of psychiatric units are that patients wander freely around the unit. Consequently, whenever I walk onto the unit, I often have interactions with one or more patients, just in the short distance between the door and the nursing station. Some of those are brief but still give me a sense of how they are doing at that point, other interactions involve brief questions from the patients, still others involve walking to the patients' room and sitting down to discuss a particular issue in greater depth with the patient and/or family.

Each of these involves a direct patient to clinician interaction and require that I exercise judgment (often a judgment that they're doing OK). Yet none of these are billable interactions and most are not documented.

I was aware of this from my own medical school clerkship in psych. The fact that these valuable interactions are largely undocumented (except in the physician's gray matter) merely shows that modeling the real world of healthcare into neat, tidy little containers of information is harder than modeling the inventory and sale of widgets, due to the complexities of healthcare. One more of those "EHR as panacea" exceptions ...

(And even the modeling of widgets isn't always done well. I went to my local MicroCenter last week seeking an EIDE-to-USB hard drive enclosure, to use the orphaned 80Gb hard drive I upgraded in my Mac Mini to serve as a Time Machine backup drive. Their inventory system showed they had a dozen on hand; nobody could find them, anywhere. A week later - yesterday - the same situation prevailed.)

Finally, a quibble. Later in the exchange Dr. Yong Kim makes the statement that "Right now, the physicians who are running these hospitals have never been trained. Most of them have never been trained in system thinking, in strategy, in management."

As most hospitals are not run by physicians, I'd have to disagree with that statement. It perhaps should be redirected to the non-medical businesspeople in the C-suite and on the hospital Boards who do run hospitals, to which I'd add "who have never been trained in biomedicine."

-- SS

Have we suffered a complete breakdown in the scientific method with regard to EHR and clinical IT?

Have we suffered a complete breakdown in the scientific method with regard to EHR and other clinical IT?

I read announcements like this with trepidation:

http://govhealthit.com/articles/2009/03/31/sebelius-confirmation.aspx
“The goal,” Sebelius said, “is to provide every American with a safe, secure electronic health record by 2014." The nominee also endorsed efforts to use data gleaned from electronic medical records to conduct “comparative effectiveness research" (CER) to provide information on the relative strengths and weaknesses of alternative medical interventions to health providers and consumers.”

Recovery Act funds have been allocated to NIH specifically for comparative effectiveness research. NIH has further specified the definition of CER as:

"[A] rigorous evaluation of the impact of different options that are available for treating a given medical condition for a particular set of patients. Such a study may compare similar treatments, such as competing drugs, or it may analyze very different approaches, such as surgery and drug therapy."

NIH states that such research may include "the development and use of clinical registries, clinical data networks, and other forms of electronic health data that can be used to generate or obtain outcomes data as they apply to CER."

The problems I foresee concern the word "rigorous" as in the above definition.

The use of EHR data to reliably detect uncommon (but strong, discrete) early warning signals from a single drug or treatment -- to then be subject to more rigorous study with reasonable controls -- is itself a Medical Informatics "Grand Challenge." An example would be finding VIOXX's association with myocardial infarction earlier than we did, via an EHR-based automated postmarket surveillance process.

Doing this is a "grand challenge" due to the nature of EHR data, which is as far from "clinical trials clean" as possible. It is what might be called highly uncontrolled. The statistical methods needed to reliably pull signals out of the muck for even a single drug are still exploratory, the problems formidable if one wants to stay scientifically sound. I wrote about the experimental nature of such efforts a few years ago here, and believe an effort got underway at U. Indiana/Regenstrief to test such methodologies for postmarket surveillance about the same time.

Now we have had what appears to be a leap of faith and logic of irrationally exuberant proportions, and probably a deviation from sound science as well. The government has announced enthusiasm for EHR data-based comparative effectiveness research (CER) not to aid science, but to cut costs (implying skipping the rigorous confirmatory phases) through elimination of more costly drugs and treatments deemed less effective or at effectiveness parity compared to less expensive choices. Following this thinking, perhaps in the future a metric will be developed for an "acceptable" improved benefit/cost ratio for expensive drugs that are better than cheaper alternatives?

This overconfidence in EHR data is of concern. To detect relatively less concrete (i.e., than major ADE) "outcomes differences" between two or more drugs or treatments via EHR data - did treatment A lower blood pressure more than drug B, did drug C lessen depression more than drug D - rises to the level of "grand overconfidence in computing." To accomplish this task with reasonable scientific certainty from reams of EHR data, originating from different vendor systems, input by myriad people of different backgrounds with differing interpretations of terminologies (students/MD's/RN's etc) under different pressures (time, reimbursement maximization), and so forth, seems a stretch. What will the p values and predictive values be for such studies? Yet our incoming HHS secretary touts such methods?

Ironically, the gold standard in medical science is the controlled clinical trial, yet EHR-based comparative effectiveness research itself as a research methodology, now touted by our government, seems to have gotten a pass.

Even what I would consider minimum requirements for scientific treatment comparisons, such as well designed and reasonably controlled registries as developed here for interventional cardiology, with hundreds of granular, finely defined and "tuned" data elements, appear to be bypassed in EHR "miracle claims." Such precise registries take months or years to develop, implement, and train users to interact with properly. Further, such registries are not portable and must be created for individual medical domains and subdomains. Uncontrolled EHR data is no substitute for such efforts.

The following question arises:

Where are the comparative effectiveness studies that compare 1) EHR-based comparative effectiveness studies of drugs and treatments to 2) controlled clinical trials-based comparative effectiveness studies?

In other words, where are the meta-clinical trials that compare EHR data mining-based comparative effectiveness research as a methodology, vs. the "traditional" gold standard methodology of controlled clinical trials to compare drugs or treatments? How do we know EHR-based CER studies will not produce GIGO that will cause harm through ham-fisted elimination or defunding of useful treatment options?

While there are initial efforts underway to increase understanding of CER, e.g., "Broad Challenge Area 5" (PDF) of the NIH RC1 Challenge Grants in Health and Science Research, ominously, there is a lot of potential advantage to be had with terabytes of uncontrolled data and a political agenda.

I fear that what will come from "comparative effectiveness research" that draws upon uncontrolled EHR data will be politics masquerading as comparative effectiveness research. Good luck to private practitioners and medical innovators. Good luck, pharma. Good luck, patients.

This movement towards EHR uncontrolled data alchemy represents a further deviation from medical science towards the Syndrome of Inappropriate Over-Confidence in Computing (a.k.a. SICC Syndrome) writ large.

It seems the IT industry has now rendered a scientific approach to HIT and its use obsolete. We see this "post scientific era" phenomenon in the takeover of clinical IT by vendors who contractually demand suppression of sharing of problems, we see it in a remarkably uncritical push for EMR's by 2014 now involving force of government (only financial at present, but will punitive licensure issues and other measures be off the table?) despite a growing body of literature advising caution, we see a consortium of big business/payers/vendors/myriad secondary feeder organizations gunning full blast for this technology without consideration of the possible downsides.

Biomedical informatics, a scientific discipline (at least those parts of it not yet compromised by conflicts of interest), as a relevant field is very much a minority player in today's health IT.

Even the contributions from experts and pioneers in the field of Biomedical Informatics, in the form of the Jan. 2009 National Research Council's report that "Current Approaches to U.S. Health Care Information Technology are Insufficient" (here) has not had much impact.

I see Biomedical Informatics' death as a relevant discipline that anyone of importance pays attention to, not too far down the road as well.

-- SS

Addendum April 20:

We've seen this phenomenon in our economy. WSJ "Information Age" writer L. Gordon Crovitz notes:

... In a paper for the scientific journal of the Royal Society back in 1994, Harvard economist Robert Merton wrote that "any virtue can become a vice if taken to extreme, and just so with the applications of mathematical models in finance practice." We know even better now that some risks can be calculated and thus reduced, while some unknowns cannot be turned into probabilities. "The mathematics of the models are precise, but the models are not, being only approximations to the complex, real world."

I believe EMR data at best is a very loose approximation to the real world. It contains many "unknowns" regarding quality and reliability that cannot be turned into probabilities no matter how fancy the math. Asking too much of EHR data becomes a vice, not a virtue.

-- SS

Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop

A preprint article "Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop" by Bonnie Kaplan and Kimberly D. Harris-Salamone (doi:10.1197/jamia.M2997) has just been published and made available in the Journal of the American Medical Informatics Association (JAMIA). It will appear in the May/June 2009 issue of JAMIA.

[Addendum 1/2010: a link to a free PDF of the published article is here.]

There is a history to this publication, that summarizes the findings and recommendations of a surprisingly well attended workshop ironically named "Avoiding The F-Word: IT Project Morbidity, Mortality, and Immortality." The workshop was held at the 2006 national meeting of AMIA.

Ten years ago, in early 1999 I started a website hosted on AOL, and called at that time "Medical Informatics and Leadership of Clinical Computing: Common Examples of Healthcare IT Failure." A historical version of the site (with a "politically corrected" title) is here; the modern site is now here. The website was unique at the time and today, remarkably, remains nearly so (see this pdf poster from AMIA's 2006 annual meeting).

Yet I was to soon learn through correspondence about the website that these problems were common as well as international in scope.

Healthcare IT failure was (and is) a somewhat "taboo" subject, in no small part because of contractual gag clauses on users and vendor lack of legal accountability for defects, as well as a striking overconfidence in computing and timidity about discussing organizational failure and IT mismanagement. Its open discussion has therefore been severely impaired and minimized.

I pushed this topic hard among the Medical Informatics community, yet for years there was resistance to bringing this issue to the fore. I took significant "heat" for my views as well, making me somewhat of an outcast in my own professional community and even to one of my former mentees. This phenomenon may have been a combination of academic concerns about a topic that might dilute the field, preferential and understandable focus on successes, conflicts of interest, and other issues.

[May 2009 addendum: the "taboo" nature of the subject of HIT difficulty and failure might in fact have been engineered by the HIT industry; see the article "The Machinery Behind Healthcare Reform: How an Industry Lobby Scored a Swift, Unexpected Victory by Channeling Billions to Electronic Records" by Robert O'Harrow, Jr., May 16, 2009, Washington Post -- ed.]

I, on the other hand, having been (pre-informatics fellowship) a Medical Review Officer in the medical department of a regional mass transit authority, and observing a fatal subway elevated accident related to drug abuse, was not going to back down.

The accident was the worst in perhaps sixty years in Philadelphia, with hundreds of injuries and several deaths in part due to overriding of medical judgment by non-medical personnel on drug testing at time of union-demanded reinstatement of persons known to have problems. This was as a quid pro quo for labor contract approval.

Worse, there were IT errors as well -- again with overriding of medical personnel, namely, me. I'd written a program on our departmental PC for random drug test date selection, but by MIS edict, use of that program was overridden in favor of some slop they authored for their machines - which "forgot" to enroll the operator behind the accident in random testing altogether. Months went by with no tests, and then at the time of the accident the operator's cocaine metabolite levels "blew the lid off the GCMS machine", according to the toxicologist performing the test.

Having been informed by my earlier transit authority experience (and gaining some lessons in fortitude from the militant mass transit labor unions I had dealings with), I started the HIT difficulties website in late 1998-early 1999 after watching ICU patients needlessly being put at risk and the high risk Invasive Cardiology cath lab being disrupted as CMIO at Christiana Care in Mr. Biden's home state. These problems were once again due to the ill-informed, capricious edicts of overempowered MIS leaders, sanctioned by equally ill-informed executive leadership.

In fact, I quit that CMIO role, no longer being able to tolerate being a marginalized "Director of Workarounds to Dangerous Health IT Mismanagement" (as are many of today's CMIOs), unable by management caprice to make even the most basic of corrections to obvious and risky implementation errors.

With the exception of a period of time in pharmaceutical research IT from 2000-2003, I periodically sought additional case information on healthcare IT difficulties from colleagues via email and AMIA message board postings, but the results were lukewarm at best.

I'd hoped upon returning to a focus on the healthcare provider IT sector in late 2003 that conditions in that sector would have improved. I was wrong. I continued to comment on these issues but with results similar to the past.

However, as more informaticists became familiar with the organizational and clinician chaos that ill-conceived clinical IT and/or suboptimally managed electronic medical records projects were causing, a "critical mass" of interest and determination appeared to have been reached by early 2006.

At my request my assigned research assistant at Drexel sent out the following message to a number of AMIA message boards, the clinical information systems (cis), ethical, legal and social (els), evaluation special interests (eval-sig) and the people and organizational issues (poi) workgroups.

From: poi-wg-bounces@mailman.amia.org [mailto:poi-wg-bounces@mailman.amia.org] On Behalf Of Yunan Chen
Sent: February 27, 2006 8:46 AM
To: cis-wg@mailman.amia.org; els-wg@mailman.amia.org; eval-sig@mailman.amia.org; poi-wg@mailman.amia.org
Subject: [poi-wg] Healthcare IT failure cases

Hello:

My name is Yunan Chen and I am a research assistant for Dr. Scot Sliverstein in the Institute of Healthcare Informatics , College of Information Science & Technology at Drexel University . Currently, we are working on a project regarding Healthcare IT infrastructure failures.

The purpose of our project is to investigate why Healthcare IT infrastructure may fail from a social- technologic perspective. We will collect cases published in scientific papers and newspapers, as well as unpublished stories by the Healthcare IT practitioners. Then, we will categorize these cases and build a casebase for future implementation guideline. We have already collected some cases which are listed in: http://home.aol.com/medinformaticsmd/failurecases.htm . The cases listed here were collected from 1998-2001. Now we hope to gather newly happened cases to enrich our collection. If you experienced or heard of any interesting story, please do not hesitate to write it down and send it to me. We hope to hear more from healthcare IT practitioners' hand-on experience. Any story is valuable to us. Any posting of the cases will be keep anonymous and we won't reveal identities of people or organizations .

We will move the Healthcare IT failure cases webpage to Drexel University server later, so all your stories will be listed on that site. We will inform you once the new website is ready.

If interested, please write back to me at: yunan.chen@ischool.drexel.edu . Comments and suggestions are welcome. I am looking forward to hearing back from you. Thanks very much.

Yunan Chen
Doctoral student & Research assistant
Institute of Healthcare Informatics
College of Information Science & Technology
Drexel University

It soon became apparent that a critical mass had been reached. A torrent of shared experiences of HIT difficulty in the various message boards appeared from all over the country and from other countries as well.

Calls for a formal AMIA panel or workshop on this issue arose. This call was energetically supported by a heterogeneous and widespread group of informatics professionals.

This momentum prompted the "Avoiding The F-Word" workshop to be collaboratively formulated in a wonderful volunteer effort led by former colleague Bonnie Kaplan at the Yale Center for Medical Informatics (where I'd completed my postdoc in medical informatics), and Kim Harris-Salamone, along with the AMIA workgroup members.

Ten AMIA workgroups and over fifty HIT experts ultimately participated in the workshop.

In Sept. 2006, before the workshop occurred, I wrote at "The holes in the quest to enable the electronic clinical trial ...":

... I also think some answers to the question "Where are the holes in the quest to enable the electronic clinical trial?" will be found in an upcoming Nov. 2006 American Medical Informatics Association Annual Conference workshop on healthcare IT failure entitled "Avoiding The F-Word: IT Project Morbidity, Mortality, and Immortality", the first of its kind:

SESSION DESCRIPTION

Recent studies of health care computer applications and the reported failures of well-known systems surprised the medical informatics community, leading to questions of how to increase the chances of IT systems success and the reduction of errors.

Similar problems plague a variety of different systems, whether for institutions as a whole, for ancillary services, or for consumer health, and have done so for many years. Despite an accumulation of best practices research that has identified a series of success factors, some 40% of information technology developments in a variety of sectors are either abandoned or fail, while fewer than 40% of large systems purchased from vendors meet their goals. According to the recent CHAOS Report by The Standish Group, which surveyed failures of IT in general (not just in health care), only 34% of IT projects were considered truly successful. Similar numbers have been estimated for health care, and the number has unfortunately remained approximately the same for at least the last 25 years. While there have been some published reports of failures, removals, sabotage of systems, or how failures became successes or were otherwise redefined, there has been too little opportunity to learn from studies in which technology interventions resulted in null, negative, or disappointing results.

The purpose of this session is to examine why this happens and what might be done to improve the situation, and to collaboratively develop a series of frameworks for various types of systems and healthcare settings to aid in implementation and evaluation. The session builds on a lively exchange by numerous members of a number of AMIA Working Groups concerning success and failure in medical informatics.

The session will be devoted to better defining or characterizing "success" and "failure." From there, participants will break out into smaller groups to continue the discussion, develop a set of important issues, action items, and recommendations.

The report, now published, is filled with pearls such as these:

• With the US joining other countries in national efforts towards the many benefits health information technology use can bring for health care quality and savings, recent sobering reports recall the complexity and difficulties of implementing even smaller-scale systems. Despite best practice research identifying success factors for health information technology projects, a majority, in some sense, still fail.

• With the United States Congress appropriating more than $20 billion for health information technology as part of the February, 2009 economic stimulus package, the US joined other countries in national efforts towards the many proven benefits such technology use can bring for health care quality and savings. Moreover, Medicare, along with private and commercial health plans, is implementing a new paradigm for paying for health care services in the US, known as Value-Based Purchasing (VBP), or pay for performance initiatives (P4P). These initiatives rely heavily on using electronic health records to provide clinical documentation that proves the value of their services. Tempering the fervor, though, are recent sobering reports that raise concerns about how the technology is designed and deployed.

• Similar failure rates [to other types of IT] have been reported for health IT.(14, 15) Hospitals are among those organizations where delays and cancellations of software projects are endemic.(16) For years, problems have plagued the implementation of health IT applications, whether for ancillary services, for whole institutions, for regional or national systems, or for consumers. Today's problems are reminiscent of those analyzed since at least the 1970s in classic studies of hospital information and patient record systems.(17-19) In 1990, Dowling estimated that staff interfere or sabotage with "nearly half" of projects(20), while Heeks noted in 2006 that it is his "best estimate...that most HIS [health information systems] fail in some way."(15) Recent studies and newspaper accounts cite difficulties in a variety of health information technology applications. Over the years, in many countries, patterns of severe problems repeatedly have beset a variety of efforts: hospital information systems and electronic records(21-26); ambulance services(27, 28); community, regional, and national health information networks (28-33); public health systems (34, 35); patient education (36); and physician order entry.(18, 19, 37-41)

• Yet, while there have been some published research reports of health care IT failures, unfortunately, there has been an absence of systematic and thoughtful publication of lessons learned from IT interventions where there have been null, negative, or disappointing outcomes.(27, 53) Despite calls for increased research, there are insufficient numbers of published research reports of health care IT failures, removals, sabotage of systems, or how failures became successes or were otherwise redefined. As in other sectors (69), IT-related failures in health care often are covered up, ignored, or rationalized, so mistakes are repeated.
  

• Participants emphasized that communication and workflow issues add to project complexity. Health care requires collaboration, as does system implementation, yet there is difficulty in translating among specialties, stakeholders, clinicians, and implementers, sometimes to the point of a seeming "culture clash."
  

• The workshop concluded with reports from break-out groups charged with discussing ideas for how AMIA could address health informatics failure. Break-out groups made suggestions concerning: research and publication, best practices, advocacy, education, certification, and databases and knowledge integration.

The workshop findings concluded with these words of wisdom:

Much has been learned about success and failure in IT implementation, but we need to understand more. There are legal issues when a system "fails," including just what constitutes "failure." There are social issues, ranging from how such failures affect various groups and health informatics as a whole (including possible policy and regulatory reactions), to the social aspects of what makes for a "successful" implementation. Finally there are ethical issues involved in evaluating system "success" or not sufficiently attending to previously-identified success factors and best practices.(24)

Most "failures" are failures to properly apply managerial wisdom that has been substantiated by research and experience. Perhaps the worst aspect of failure is failure to learn from past experiences so that the same issues and problems are not perpetuated.

While the workshop was a culmination of the kindling on this crucial topic I've been involved in since being overruled on patient-endangering healthcare IT mismanagement, I believe we as a society, and the HIT sector as a for-profit, entirely unregulated industry lacking accountability (the accountability rests on clinical end users, as in, in the courtroom in malpractice suits), are still very far from solutions to that final observation on failure to learn from history.

The observations of this workshop are only made more acutely important by what I believe are ill advised, rushed plans to coerce US healthcare organizations and practitioners to adopt these evolving, arguably still-experimental virtual medical devices by 2014, or face penalties.

-- SS

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

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

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