Pages

Thursday, December 03, 2009

Healthcare IT Failure and The Arrogance of the IT Industry

In the Wall Street Journal healthcare blog post "Safety Guru: ‘Health IT Is Harder Than It Looks’" here, reporter Jacob Goldstein reports on UC San Francisco hospitalist Bob Wachter's commentary that:

... recent experience has confirmed that health IT is harder than it looks … Several major installations of vendor-produced systems have failed, and many safety hazards caused by faulty health IT systems have been reported.

I would differ with Dr. Wachter only in that the "experience that health IT is harder than it looks" goes far beyond "recent", e.g., as in the wisdom of the Medical Informatics pioneers from the 1960's-1970's and earlier as in my post "Medical Informatics, Pharma, Health IT, and Golden Advice That Sits Sadly Unused" here.

One comment to the WSJ posting, however, caught my eye. It is a common refrain heard from the IT industry and from health IT amateurs (a term I use in the same sense that I am a radio amateur) unaware of decades of research in the sociotechnical aspects of computerization, i.e., medical informatics, social informatics [1], human computer interaction, etc.:

Commenter: "I have seen very few health IT products that actually harness the power of the computer. Bob is right about “implementation without changing processes” - we need companies to stop asking docs and hospitals how they can duplicate the paper chart and instead work with docs and hospitals to make things work better than the old way."

I take the opposite view.

In reality, handwriting issues aside, there is little wrong with "the old medical chart" from an information science perspective. It evolved over a century or longer to serve the needs of its users. It is a simple document in terms of organization, containing sometimes complex information but in an easy to find form (when maintained by humans properly) and in a presentation style that recognizes human cognitive limitations in very busy, complex social environments such as patient care settings.

Its quasi-duplication in electronic form would serve medicine well.

Instead, like the OS bloat that has now left room for newcomers such as Google Chrome OS to demonstrate the virtues of simplicity, we have markedly complicated EHR's with a large number of screens, subscreens, widgets, controls, scroll bars, alerts, navigation aids, and other "bloatware" that bog the clinician down. (A paper chart and pen do not require a 500+ page user manual as do some EHR's).

The "power of the computer" and its programmers to create complexity is what slows physician down and creates myriad opportunities for unexpected adverse consequences, often through the mission hostile user experience presented to clinical users [2]. This is not to minimize the issues of implementation debacles and upheavals [3,4], bugs, errors, unpredicted dependencies and interactions (e.g., per Koppel's articles on CPOE [5] and barcoding [6]), and other problems unavoidable in any massively complex computer information system [7].

In fact, politically speaking, health IT can be viewed as a cross-occupational invasion of healthcare by the IT industry. (Other invaders are at work also, but I am only considering the IT industry here.)

The latter industry is largely healthcare-dyscompetent or incompetent [8] while simultaneously highly arrogant, perhaps as a result of the acculturation common in the field [9].

I ask:

What right do the domain-dyscompetent occupants have to tell the occupees, the latter rigorously trained in clinical medicine through years of both classroom and grueling practical experience, and in the record keeping paradigms developed over centuries, how to maintain their records and perform their processes?

What arrogance is it that drives the the occupants to tell the occupees to stop complaining about the terms of the occupation - seriously deficient experimental health IT applications - and get in line with the methodologies and preferences of the occupants?

The pace of articles showing the lack of return on investment of health IT is accelerating (see, for example, "2009: A Pivotal Year in Health IT" here). The reasons for this failure can be explained by a simple triad:

  • Health IT is an experimental technology.
  • The vendors promote it as a well tested, validated, tried and true healthcare "cure."
  • Reality is a harsh master.

Until the arrogance of the IT industry is recognized and countered - even if it comes to, in a quasi-comical suggestion, the doctors arming themselves with scalpels and cutting every network cable in sight - and it is recognized that experiments conducted under false assumptions are doomed to fail - our approaches to health IT, per the National Research Council, will remain insufficent [10].

The latter organization recommended that health IT success will depend upon accelerating interdisciplinary research in biomedical informatics, computer science, social science, and health care engineering.

This research will be a long time in coming if we as a society are still at the level of arguing about whether "health IT is harder than it looks" and about the unproven and arrogant assertion, made with a straight face by process re-engineering analysts and consultants seeing money to be made and with little consideration of unforeseen side effects, that the computer will achieve miracles only when we "change medical processes" [i.e., adjust medicine, the occupee, for the convenience of medicine's occupiers, the IT industry].

-- SS

Notes:

(numbers hyperlink to source)

[1] Understanding And Communicating Social Informatics. Kling, Rosenbaum & Sawyer. Information Today Press, 2005.

[2] Are Health IT Designers, Testers and Purchasers Trying to Harm Patients? S. Silverstein MD. Healthcare Renewal Blog, eight-part series, http://tinyurl.com/hostileuserexper

[3] H.I.T. or Miss: Lessons Learned from Health Information Technology Implementations. AHIMA Press (2009), ISBN: 9781584262404. (Disclosure - I am an associate editor of this book).

[4] A Critical Essay on the Deployment of an ED Clinical Information System - Systemic Failure or Bad Luck, version 6. Prof. Jon Patrick, Health Information Technologies Research Laboratory, University of Sydney, Australia,
Dec. 2009.

[5] Role of Computerized Physician Order Entry Systems in Facilitating Medication Errors. Koppel et al., Journal of the American Medical Association, 2005;293:1197-1203

[6] Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes, and Threats to Patient Safety. J Am Med Inform Assoc. 2008;15:408-423

[7] Pessimism, Computer Failure, and Information Systems Development in the Public Sector. Shaun Goldfinch, University of Otago, New Zealand.
Public Administration Review 67;5:917-929, Sept/Oct. 2007.

[8] Hiding in plain sight: What Koppel et al. tell us about healthcare IT. Christopher Nemeth, Richard Cook, J Biomed Inform. 2005 Aug;38(4):262-3

[9] Defensive climate in the computer science classroom.
Barker et al. ACM SIGCSE Bulletin, Volume 34 , Issue 1 (March 2002)

[10] Current Approaches to U.S. Health Care Information Technology are Insufficient. The National Academies, Jan. 9, 2009.

9 comments:

  1. "The user is unimportant" was oft repeated in the introductory programming class I took earlier this decade. I think the idea was that we should not let "business" taint the process of programming.

    Perhaps one of the reasons there are problems is that the process does not start with health caregivers, but instead in administration and IT departments who determine the structure and hire the software people before bringing in the users.

    Ultimately, I think the point of EHR is to make the health records of all US residents available to the government. It isn't really about better hospitals.

    ReplyDelete
  2. "The user is unimportant" was oft repeated in the introductory programming class I took earlier this decade. I think the idea was that we should not let "business" taint the process of programming.

    I am going to be unequivocal about this.

    Anyone proffering such advice is a fool. Computer programs are not sacred text deserving of purity unaffected by the dirtiness of the non-virgin real world.

    It is precisely due to a lack of understanding of the business and of the users by designers, developers, programmers and implementers that IT fails.

    ReplyDelete
  3. As neither a clinician nor an IT expert but one of the many who has been put in the middle in recent years, I have a question. Given the cognitive and technical inefficiencies of computers, if we are just going to recreate the paper chart why bother with EHRs at all?

    ReplyDelete
  4. "Given the cognitive and technical inefficiencies of computers, if we are just going to recreate the paper chart why bother with EHRs at all?"

    For many of the reasons commonly stated about EHR's, which are, I believe, achievable. Improved availability of information, improved research capabilities, possibilities enabled by decision support tools, etc.

    "Reproducing the paper chart electronically" refers to a "keep it simple" information presentation style and the overall user experience presented to clinicians.

    The overly complex user experience of today's EHR products may in fact be serious overkill.

    -- SS

    ReplyDelete
  5. These comments present contrastive positions of on the one hand saying the design of the paper chart has a 100 years experience in it and is efficient versus the other argument that says lets use the computer to change things.

    We have to recognise the value of both these views. We can't totally disrupt existing ways of working in places like hospitals because the risk of something going wrong is the death of people. Secondly the IT needs within a hospital are non-deterministic, that is, they can't all be predicted in advance. Also, they are part of a complex system that is they will change over time.
    Also the easiest way to introduce any change in technology is to create the least disruption. These three axioms imply that we have to firstly reproduce the existing methods of work in the hospital and then gradually and by negotiation introduce changes to those methods that can be enhanced by IT. This requires a different software engineering paradigm, that of the most recent methods such as agile computing.

    ReplyDelete
  6. jon patrick wrote:

    These three axioms imply that we have to firstly reproduce the existing methods of work in the hospital and then gradually and by negotiation introduce changes to those methods that can be enhanced by IT.

    Agreed. Key terms: gradually, by negotiation, enhance (not "revolutionize.")

    -- SS

    ReplyDelete
  7. Very well stated, Scot; and JP, you are an HIT folk hero for getting your report out there.

    HIT systems are unlikely to provide meaningful efficiencies in care as long as they remain unsafe due to a myriad of the problems known to exist.

    JP, it would be helpful to organize a user friendly program to get users to establish the magnitude of the near misses and adverse events befalling the patients whose care is affected by HIT electronic ordering and physician data entry programs.

    I think that the incidence is sufficiently high that you would only need to collect data for a month to prove the meaningfully uselessness of some of these systems, especially the Farcenet.

    ReplyDelete
  8. At risk of arrogance, an outsider suggests that several issues exist.

    The easiest is the arrogance of IT. This stems from the fact that computers were, for a number of years, the largest and most resource-intensive assets that many computer-using entities owned. As a result, IT personnel attached at an organizational level far higher than would have been the case had those peoples' actual function been the basis for the attachment point. IT departments therefore had unfiltered input to senior management that drove operations to fit the computer rather than vice versa. We may never recover from the resulting attitudes and distortions. It would be nice were this the only problem; it could be addressed and isolated, but...

    Next is the procedural questions: WHo will own the EHR? Who will have access to it? Who will be able to write to it? Who will edit and/or maintain it? How will errors or even changes be entered? Who will have the capability and responsibility? These issues are all self-evident when my doctor has my paper chart sitting in his file cabinet. The instant the chart leaves the cabinet, even in paper form, the opportunities for mischief blossom.

    Economics: If the goal is to electronify the existing chart, where's the payoff? Benefit to the patient is obvious, but that's not where the big lumps of cash reside. Euphemisms about "using the power of the computer," "efficiency," and the like are cover for somebody wanting to not merely reduce errors and make records portable but to allow data mining, product placement, or other money-making opportunities.

    And the elephant in the room, legal. No further comment required.

    ReplyDelete
  9. Michael,

    Arrogance towards whom?

    Thanks for the comments and interesting observations about how IT achieved a higher level in healthcare organizations than their limited-to-no medical experience justify to any sensible person.

    This perhaps explains how I could inform IT personnel that their hanging standard business class computers on the ceilings above the beds of ICU patients could likely end up killing people, and then to be completely ignored due to remediation being an IT "inconvenience."

    Further, "IT puffery" has no place in medicine.

    Finally, I ask the question: could the same document imaging system I used to manage my departmental budget in Big Pharma, along with just a bit of discrete data akin the the index card summaries I used to prepare during patient signout to on call docs, serve a large proportion of the needs of clinicians and patients in the ambulatory setting?

    Could that technology also serve the needs of bureaucrats, too, if they hired the resources to utilize them instead of wasting clinician's valuable time turning physicians into clerical aides?

    -- SS

    ReplyDelete