Status Quo Kills

Dear Reader,

Most health IT projects fail because the software industry’s dominant response to the software crisis precisely collides with the unique demands of health IT.

Ever since Edsger Dijkstra began theorizing about how to solve the software crisis in 1972, computer science has focused understandably on the need to drive down the rate of errors in order to produce correct code. This focus on reducing errors has led to a focus on careful specifications and the careful coding designed to measurably meet those specifications. Under this paradigm, which is taught in all computer science departments across the country and followed by the software industry, success is defined as adherence to a software specification and errors as deviations from that specification. This error-avoidance philosophy is so ubiquitous, it is even implicit in the success and failure critieria used by The Standish Group in its CHAOS reports.

The resulting software-development process drives toward achieving the fixed goal of compliance with the specification, toward achieving a kind of crystalline, static perfection. That is, for the software-development process to avoid errors as much as possible, it has to impose extensive testing on all changes, which raises the cost and time required to make changes, which has the effect of discouraging changes. Indeed, everything about the dominant software paradigm rewards compliance with specifications and punishes attempts to modify the specification, especially in mid-course. It is a specification-driven, stasis-seeking methodology hostile to change. It dominates the software industry, including those companies engaged in producing health IT.

The problem with trying to apply such a model to healthcare is twofold.

First, healthcare is extraordinarily complex, essentially impossible to capture in a specification, which guarantees that any specification will deviate from the actual needs of the users. When faced with a choice between a clear specification and ambiguous statements of need, the specification-driven, stasis-seeking paradigm will always choose the specification over reality.

Second, even if it were possible to capture a perfect specification of the needs of health IT adopters, medicine changes continuously in response to the continuous scientific investigation into health and the resulting continuous stream of new discoveries that impact best practices. Hence, even a correct specification would become increasingly incorrect merely through the passage of time.

Healthcare is thus the worst possible case for the dominant software paradigm: an unspecifiably complex problem domain that continuously changes.

Unfortunately, health IT vendors have two overpowering incentives to disregard this fundamental mismatch of their approach and their subject.

First, the logic of avoiding errors seems irresistable, particularly so when backed by the consensus of an entire industry and its corresponding field of science; when struggling to gain control over out-of-control software projects, the retreat to controlling errors intuitively feels like the right move.

Second, the status quo is very, very profitable, especially because of the mismatch with the needs of healthcare. To help discourage changes to the specification in mid-course, it is standard procedure for IT companies to charge exorbitant premiums for such mid-course spec changes. The mismatch between health IT specifications and real healthcare information needs guarantees that health IT projects will involve a great many changes to the specification, for each of which the health IT vendor will earn a premium. The cost overruns that health IT adopters lament are the profits that keep health IT vendors in business.

In short, when applied to healthcare the dominant specification-driven, stasis-seeking, error-phobic software-development culture kills, but it does so both profitably and untraceably.

Yours truly,
Rick

Postscript: Let no one—no one—infer from this posting that I have anything less than respect and admiration for the great Edsger Dijkstra. My argument is that automating rapidly changing fields like medicine is a special case in which Dijkstra's prescription is not the best solution for addressing Dijkstra's concerns.

The Risks of Health Information Technology

Dear Reader,

Health IT success or failure numbers are very hard to come by, in part because some healthcare IT vendors require their customers to sign contracts banning them from publicly discussing the success or failure of their health IT, in part because the legal stakes are much, much higher with health IT failures which creates a disincentive to be forthcoming about dramatic failures.

Most numbers therefore are anecdotal. For example, the American College of Physician Executives (ACPE) surveyed its thousand members in its 2004 Technology Survey, and the results suggested that even successful health IT projects are often more expensive and less useful than expected, often permanently reducing physician productivity.

Informal surveys of non-management medical professionals at hospitals adopting IT reveal a much lower rate of satisfaction than that reported by those in management positions. The most frequent complaints are (1) a poor fit between the software’s design and the needs of its users, (2) poor responsiveness to requests to improve the software, and (3) hidden and horrendous costs that emerge in IT adoption during the process of trying to get badly fitting software changed to truly meet the needs of its users.

Off the record health IT programmers are often surprisingly candid about how bad their software is and about how resistant health IT company management is to making unprofitable changes that would improve its quality. Producing bad health IT software has been very profitable for a long time.

Health IT is the industry that results when one industry in crisis attempts to assist another industry in crisis, creating a collision of crises. The emergence of an American health IT movement is an important step toward improving health in this country, but unless the true state of health IT is understood and dealt with it will almost certainly be a very painful step indeed.

Yours truly,
Rick

The Risks of Information Technology

Dear Reader,

Unfortunately, missing from all this discussion is an appreciation of the dark side of health IT. Unless the problems with American health IT are as openly discussed, understood, and dealt with, as the problems with American healthcare, mixing IT with healthcare could deepen our national healthcare crisis.

The problems with health IT begin with IT itself. According to The Standish Group’s CHAOS 2004 survey results, only 29% of software projects come in on time, on budget, and with all the features originally planned. 53% of software projects fail at least partially, and 18% fail completely. Although people not familiar with the sorry state of the software industry find these numbers shocking, the reality is even worse.

The Standish Group’s numbers are oriented toward tracking the effectiveness of the project management, not the effectiveness of the resulting software. Any experienced IT user can tell you that many “successful” projects are actually failures from a usefulness perspective, bad ideas successfully imposed upon the organization. Similarly, these numbers do not factor in whether the budget was an effective use of the organization’s resources. Many, many projects are vastly more expensive than they should be for the value delivered. Once these crucial but omitted criteria are imposed on the CHAOS numbers, the numbers fall in line with the reality of an industry in crisis, The Software Crisis.

Since 1968, the software industry has understood itself to be immired in a crisis that defies solution. Forty years of innovation have still not managed to fix the kinds of problems measured by The Standish Group. Indeed, they have only clarified that at the root of the problem is a basic but paradoxical principle of complexity: Success breeds failure. Success with software development invariably increases the amount of software to be managed and taken into account in the next round of development. There is no limit to the potential complexity of software, but human capacity for managing complexity begins to fall apart at surprisingly low levels of complexity.

Successful software lifecycles become less successful over time. No wonder so many software adopters cyclically opt to replace what they have with something new! The temptation to blame the current software and start over with something else helps to fuel a major portion of the healthcare IT industry’s annual revenues. This wheel spinning may be successfully executed as projects and reported as such in the CHAOS reports, but it constitutes ongoing waste and failure disguised as success.

The consequences of our limitations are starkly illustrated by two parallel trends. First, at the same time that the hardware revolution has made computer hardware orders of magnitude smaller, faster, and cheaper, the software crisis has made software orders of magnitude larger, slower and more expensive. Second, the ability to succeed with software projects goes down dramatically as the scale of those projects increases, a factor noted in the CHAOS reports.

Yours truly,
Rick

The Importance of Health Information Technology

Dear Reader,

American healthcare is in crisis. It has been in crisis for decades, but thanks to the Institute of Medicine (IOM)’s Committee on the Quality of Health Care in America we can finally discuss it openly and objectively.

The committee’s reports—To Err is Human: Building a Safer Health System and Crossing the Quality Chasm: A New Health System for the 21st Century—have changed history by ending forever the viability of our industry’s de facto strategy of denying the problem. These landmark reports have also given us a framework for understanding the nature of the problems we face and the broad structure of the solutions we have to create and bring to bear to improve healthcare in America.

In Crossing the Quality Chasm, one of the IOM’s prescriptions for improving American healthcare is the use of information technology (IT): “IT has enormous potential to improve the quality of health care with regard to all six of the aims set forth in Chapter 2.” Indeed, the report’s ninth recommendation reads:

Congress, the executive branch, leaders of health care organizations, public and private purchasers, and health informatics associations and vendors should make a renewed national commitment to building an information infrastructure to support health care delivery, consumer health, quality measurement and improvement, public accountability, clinical and health services research, and clinical education. This commitment should lead to the elimination of most handwritten clinical data by the end of the decade.

This recommendation has launched a national discussion of the importance of health IT and strengthened the arguments of health IT advocates. Where health IT was once a technical topic of limited interest, it is now understood to be an essential component of our national strategy for improving healthcare. For example, the Commonwealth Fund’s 2003 Annual Report, Achieving a High-Performance Health System, uses language very similar to IOM’s in the report’s step four toward building a truly high-performance health system:

Invest in health information technology. Other countries are quickly surpassing the United States in adopting electronic medical records and prescribing systems. Their governments have invested in infrastructure and established the necessary standards, and the United States needs to do the same.

Increasing state and federal interest, funding, and mandates for health IT are symptoms of what has become a national health IT movement, much of which was catalyzed by the IOM’s reports. After all these years, there is a growing national consensus about the potential of IT to improve healthcare and a growing political will to do something about it.

Yours truly,
Rick

Fluxus Quo: A New Series

Dear Reader,

At Rodney Kay's request, let's postpone the continuing discussion of master planning in favor of what I agree is a long overdue topic for understanding VISTA and organic order: fluxus quo.

Since information out of context is noise, let's first explore how fluxus quo applies to health information technology (IT), to make clear why we care. Over the next few weeks, we'll run through a draft chapter of the book I'm writing on the VISTA lifecycle. This chapter makes the VISTA community's central argument about what's wrong with health IT and how to fix it. Fluxus quo is both the problem and the solution.

Yours truly,
Rick

Interlude: Horatio Smith on Shelley's Ozymandias

OZYMANDIAS
or
ON A STUPENDOUS LEG OF GRANITE, DISCOVERED STANDING BY ITSELF IN THE DESERTS OF EGYPT, WITH THE INSCRIPTION INSERTED BELOW

In Egypt's sandy silence, all alone,
Stands a gigantic Leg, which far off throws
The only shadow that the Desert knows:
"I am great OZYMANDIAS," saith the stone,
"The King of Kings; this mighty City shows
"The wonders of my hand." The City's gone,
Nought but the Leg remaining to disclose
The site of this forgotten Babylon.
We wonder, and some Hunter may express
Wonder like ours, when thro' the wilderness
Where London stood, holding the Wolf in chace,
He meets some fragments huge, and stops to guess
What powerful but unrecorded race
Once dwelt in that annihilated place.