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.