Information Technology Outside Health Care

Abstract

Non-health-care uses of information technology (IT) provide important lessons for health care informatics that are often overlooked because of the focus on the ways in which health care is different from other domains. Eight examples of IT use outside health care provide a context in which to examine the content and potential relevance of these lessons. Drawn from personal experience, five books, and two interviews, the examples deal with the role of leadership, academia, the private sector, the government, and individuals working in large organizations. The interviews focus on the need to manage technologic change. The lessons shed light on how to manage complexity, create and deploy standards, empower individuals, and overcome the occasional “wrongness” of conventional wisdom. One conclusion is that any health care informatics self-examination should be outward-looking and focus on the role of health care IT in the larger context of the evolving uses of IT in all domains.

Health care informatics tends to focus on the ways that health care is different from other information technology (IT) domains. Implicitly, therefore, the assumption is that it cannot benefit from the lessons learned in these domains. This paper, however, assumes that the use of IT in health care is like that in other enterprises and that the similarity is great enough to warrant careful examination. The conclusion is that, since lessons learned in other domains are largely ignored in health care, valuable lessons are missed. The validity of this conclusion is illustrated by examples.

Framing Observations

Health care IT may be run by those who gain their experience and success in non-health-care IT, where IT experts learn to use IT to support organizational goals productively. As Mark Frisse points out in his Wal-Mart case study in this issue,¹ the future path to management advancement in health care may be through enterprise IT. In the near term, this path may begin outside health care.

• Costs. Certainly there will be costs, both financial and nonfinancial, associated with this trend. Health care informaticians can anticipate many of these. For example, if caregivers are not part of the health care IT career path, potentially important IT functions may be delayed or missed entirely, because no one with the power to do anything knows any better.

• Benefits. There are likely to be benefits from health care IT outsourcing, both anticipated and unanticipated. We in the health care informatics field will have some insights into this, but no monopoly on it. For example, some health care IT experts observe that solving simple problems first makes the hard problems harder to solve later; but this “cost” may be offset by the benefits of the experiential learning that occurs in a given organization. More bluntly, health care IT “amateurs” may learn so much from “just doing it” that they stumble on insights and requirements missed by those who only introspect. The latter phenomenon may be accelerated by secular (background) changes in technology, e.g., the Web. The approach expressed in the software dictum “design top-down, implement bottom-up” is an attempt to benefit both from coherent vision and experiential learning, but implementing this approach at enterprise scale is difficult.

• Opportunity? We should look on this (nearly) inevitable trend as an opportunity, e.g., we can help IT professionals understand what health care data mean or don't mean.

• An external reality! Above all, the success of IT use in enterprises in non-health-care domains is an external reality that is sure to have an increasing effect on health care.

The Non-health-care Use of IT

The remainder of this paper is aimed at two goals. The first is to help informaticians specializing in health care to understand and assess the use of IT in non-health-care domains. The second is to promote discussion of the relevance, or lack of relevance, of these successes to health care.

IT Success Has Many Followers, But Few Metrics

In non-health-care enterprises, computing return on investment and other measures of IT use is still difficult and controversial, just as it is in health care enterprises,^* but there is no question that IT is essential to the success of certain non-health-care activities. We should understand what they are, because these successes influence how those in positions of responsibility think IT should be used in health care.

Where Should IT Be Used in Health Care?

Before asking whether an IT success, failure, or phenomenon is relevant to health care, we have to ask whether health care is different enough to make this question worthwhile. In other words, why can't health care use IT to advantage in the same way that other enterprises do? Other enterprises achieve economies of scale by figuring out how they are the same as other enterprises—e.g., in their use of commodity technology—and how they must be different. Why can't health care do the same? For example, Oracle Corporation outsources the management of all its paper copying services, rationalizing that it will never achieve advantage through superior, internal management of those services.^†

Examples of Non-health-care IT

To focus on some “facts,” we will examine eight domains of IT use.^‡ Some of these domains have been selected to highlight certain aspects of IT use and management, while others shed light on key challenges facing health care informatics as a profession and health care as a domain.

Each of the eight domains is presented in the following format: question, story, health care question, and discussion. The eight domains are organized into three groups, according to the sources from which the examples were drawn: personal experience, for domain 1 (academic IT); books, for domains 2 (society), 3 (Silicon Valley), 4 (the Internet and Web), 5 (legacy systems), and 6 (the U.S. Army); and interviews, for domains 7 (a financial services firm) and 8 (an applications software company).

Domain 1: Academic IT

Question: What's Happening in Academic IT?

While there are many interesting and potentially useful things going on in academic IT—e.g., nano-fabrication, with plans for angstrom-sized “agents” that transmit information, or intervene, while circulating in the blood¹⁰—most are decades away from affecting health care.

Story: “Academic IT and Me”

From my own education and work I learned that engineering is reality-focused; specifically, engineers have learned to avoid “technology for technology's sake” by focusing on the goal of engineering, namely, the “economic resolution of human need.” People have needs, and resource limitations matter.

One way I, as an undergraduate scholarship student, rationalized majoring in engineering was that it made me employable. Employability was an important consideration. Graduate stipends made it possible for me to follow my interests into academic computer science. In contrast to engineering, it was not reality-focused, and it was supported chiefly by the government. For purposes of this discussion, I have equated computer science with academic IT.

A core mantra of computer science is “simplify, formalize, scale.” By any measure it has been successful. But in health care the simplification has been so severe, usually, that the remaining functionality has not been a productive use of technology. Either human needs were not being fulfilled or the needs that were fulfilled were not economically justifiable.

In contrast, computer science has been most successful when applied to itself; for example, the RISC (reduced instruction-set computer) is hardware designed by software. For various reasons, academic computer science has been much less successful at solving problems outside itself. As Scott Blois, the first president of the American College of Medical Informatics (ACMI), once observed, formalizing relevance in a patient-care encounter is very difficult.

Computer science has produced a very powerful repertoire of abstractions representing problems that can be solved computationally. Graduate school helped me learn how to use these abstractions, and I find them useful to this day.

In conclusion, most of what I, as a health care informatician, do today makes use of engineering. But by 2003, health care enterprises may care centrally about what I have come to call “normalization of meaning at Web scale.” If so, I will need all the computer science I ever learned and more. Among other things, engineering (as a discipline) is weak on scaling through formalization. This was probably the most important lesson I learned in computer science in graduate school.

Question: “Is Academic IT Relevant to Health Care?”

In my opinion, academic IT is not going to provide answers for health care in the near term, i.e., the next three to five years. It is the expressed opinion of many informaticians that computer science is very important for the longer term—although it is not clear when, or if, academic computer science will ever focus on applications, including health care.

Domain 2: Society

This example is drawn from the book of Exodus, in the Old Testament.

Question: Will We Be Allowed into the Promised Land?

Story: Exodus

According to the Old Testament, Moses led his people out of slavery. Many in our field have tried to be Moses at one time or another. Moses and his people wandered in the desert for 40 years. Is the health informatics community wandering in the desert? The Hebrews reinvented themselves during this journey. Are we reinventing ourselves? Is the biblical notion of a generation—40 years—a euphemism for “progress by funeral”? What is the equivalent of a generation in health care informatics in the new millennium?

At the end of his journey, Moses was not allowed into the Promised Land. His nominal offense was trivial. Was his non-admittance to the Promised Land a bug or a feature—that is, are the “exodus” capabilities not what are needed in the Promised Land? History shows that revolutionaries are often terrible governors. One interpretation of Moses's non-admittance is that none of his generation deserved to be in the Promised Land.²

Question: What Is the Relevance of Exodus to Health Care?

Does health informatics matter? Are we part of the problem? That is, do we not deserve admission to the promised land? If we were forced to retire tomorrow, would health care be better off, or worse off? More subtly, how would it be better or worse off? Regardless of our answers to previous questions, will anyone want us in the promised land—assuming there is one? At present, few of us are invited into anything, although the exceptions are notable.

According to biblical scholars, the historical basis for Exodus is slight, yet the story is powerful and central to many cultures.³ In the New Testament, Luke uses the Greek word exodos when referring to one of Jesus's journeys; this was probably intentional and shows that the story had considerable power even then, 2,000 years ago and more than 1,000 years after the alleged event (C. Carlston, conversation, 1998).

Domain 3: Silicon Valley

This example is drawn from the book Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can't Get a Date, by R. Cringely,⁴ on which the television show “Triumph of the Nerds” (Public Broadcasting Service)⁵ was based in part.

Question: Was the Explosion of “Personal” IT about Technology or Personalities?

The book focuses on the personalities of several people and the key technologic and business developments they led. Is this focus correct?

Story: Empowerment of Individuals by Individuals

Chips, Apples, PCs, Macs, personal productivity software, Laserwriters, Ethernet, Suns, Web browsers, Amazon.com—these and other IT artifacts have changed the way the world lives. The background was a mainframe, high priestly approach to computing. The personalities described in Accidental Empires were able to simplify (design), satisfy (on technology), and fulfill human need (or at least human desires) economically. It is difficult to find much computer science here, although there is some; mainly market needs were fulfilled, but not in lasting ways. Consumers learned about IT experientially, for the first time, but not all the entrepreneurs learned experientially. The free market worked, however, and the evolution of certain things, like PCs, went very fast.

Question: Will History Repeat Itself in Health Care?

Will there be other entrepreneurial explosions (“accidental empires”) led by individual entrepreneurs? Or will major changes in health care happen only because of national (or international) standards, agendas, policies, infrastructure, and collaborations? One expert has suggested that the combination of biotechnology and IT may produce another accidental empire. Another proposes that consumer health information, possibly in combination with semantic message standards for laboratories, meds, and such, may be another accidental empire. Although the PC revolution seems to be over, we should plan on as-yet-unarticulated IT revolutions in health care.

Domain 4: The Internet and Web

The book NERDS 2.0.1: A Brief History of the Internet, by S. Segaller,⁶ provided this example. The book is the companion publication to the PBS documentary series of the same name.⁷

Question: How Did the Internet Come About?

We may live long enough to see history conclude that the Internet was one of the most dramatic developments of the 20th century.

Story: Industry Declined to Build It; Academia Declined to Deploy or Use It!

When the government wanted to build the Internet, IBM said, “We have the solution already,” and Bell Labs said, “It can't be done.” One of the very talented engineers who helped build it (Severo Ornstein) said, “Sure we can build it, but who'd use it?”^§

Once it was built, academia said, “We don't want it.” E-mail was the first application that made the Internet take off, but this was years after it was fully operational.

Why did it take so long to be used widely and productively? Why is it so good? Was the benign neglect required for success? Sandy Lerner, Cisco Systems co-founder, said, “The Internet is the best thing the United States bought since the Louisiana Purchase.”⁷

Question: Is the Model Relevant to Health Care?”

The Internet seemed to require that the government act as visionary, investor, and chief early user. Those who “knew better” in academia and the private sector got in the way. Was the government the only one who could focus on “scaling without bound”? The process used to develop and deploy the requisite software yielded artifacts of very high quality. Were the many years of benign neglect necessary for success, for example, to create the necessary evolutionary process? Many who built the Internet were of a different generation from those who built the accidental empires; was this a coincidence or requirement?

What can or should health care learn from the creation and adoption of the Internet? Is it true that no one “owns” the Internet? If so, is there a parallel in health care?

I don't pretend to know the answers to these questions, but I think finding the answers is important.

Domain 5: Legacy Systems

This example is drawn from the book Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach, by M. Brodie and M. Stonebraker.⁸

Question: How Does Non-health-care IT Deal with Legacy Systems?

There is an old joke that says, “A legacy system is one that works.” By definition, a legacy system is hard to modify. Migrating large, mission-critical legacy systems to new, more adaptable technology is difficult; until recently there were few successful examples. Non-health-care organizations can rise or fall because of their IT strategies; Brodie and Stonebreakers's book explains some of the reasons.

Story: “Cold Turkey” versus “Chicken Little” and “Code” versus “Data”

“Cold turkey” is the name of a legacy system strategy that deploys new systems and shuts off legacy systems by “throwing a switch.” Implied in this approach is a potential total loss of all legacy data. “Chicken Little” is a strategy whereby the incremental development and deployment of wrappers around, and gateways to, legacy systems make it possible to move selected enterprise IT functions to new systems while retaining existing data and some legacy systems. Implicit in this approach is the option to keep legacy systems running indefinitely, albeit behind wrappers or gateways that “surface” valued data in ways that are compatible with the new systems.

The core motivation behind the recommended “Chicken Little” approach is the recognition that enterprise data are what is important, not the enterprise code that manipulates them. There is a very real cost to “losing” the fact that a given patient has a penicillin allergy if a new system doesn't retain existing data. “Reminder” code that knows what to do with “penicillin allergy” is easy to replace.

Question: How Should Health Care Deal with Legacy Systems?

If IT organizations outside health care rarely turn off legacy systems until their replacement systems are running smoothly, if they turn them off at all, why do health care enterprises choose to deal with the “we'll replace everything for you” (cold turkey) vendors? If data—even old data—are more important than code outside health care, why isn't this true inside health care?

Health care IT should build on what works, at least at first. One can always turn off legacy systems once their functions have been replaced satisfactorily and reliably.

Domain 6: The U.S. Army

This example is drawn from the book There's a War to Be Won: The United States Army in World War II, by G. Perret.⁹

Question: How Can a Small Group Change a Large Organization?

What if the government is not “doing the right thing?” How can a group of individuals who are not necessarily in charge effect dramatic change and plan for a future that no one else wants to talk about?

Story: How George Marshall and Others Reinvented the U.S. Army

While the nation turned to isolationism and later struggled through the Great Depression, the U.S. Army learned from World War I, planned for World War II, and made the best use of small budgets while soldiers wore civilian clothes in public so as not to attract the attention of a hostile Congress. The army did this by planning from the top down, e.g., through widespread standardization, in a way that focused on individual and unit empowerment and laid the groundwork for an accelerated meritocracy once a conflict started.

For example, every officer was taught how to manage a single kind of attack, called a “holding attack,” that was applicable to any sized unit.^∥ Every infantryman was equipped with a shovel that had a hardened, tool-steel tip, when only elite units in the German army had such shovels. Furthermore, Marshall and others had the grit to fire most of the generals at the beginning of World War II.

The meritocracy made it possible to make tradeoffs of technology quality, timeliness, and cost under great pressure. At the end of the war the Germans had jet engines and the V-2 rocket, but the American army had the best infantry weapons in the world.

Undoubtedly, part of the reason the Allies won was air superiority; but throughout World War II the air force was still part of the army and part of the plan formulated between the wars.^¶

Question: What Are the Lessons Here for Health Care?

When things are going badly, the first requirement for improving the situation is to develop an ethic of truth telling. Truth telling can lead to useful empirical analysis. Many of World War II's successful generals spent the years after World War I gathering data, including analyzing the military demographics of battle cemeteries.

Empirical analysis can lead to a new vision, and that vision to a plan. Typically, new plans need education conducted from the bottom up and a meritocracy to back up the education and sustain the validity of the plan through feedback—part of continuing truth telling. All these things require individual empowerment in a highly standardized world.

In the end, meritocracies require tough choices on inevitable tradeoffs. Like Moses, George Marshall was not allowed into the Promised Land—he never got a field command. Roosevelt (“God”) wouldn't let him leave Washington.

Domain 7: A Financial Services Firm

This example is based on an interview with the vice president of databases at a leading e-financial services firm.

Question: How Does a Person-to-Person Business Reinvent Itself and Become an e-Commerce Business?

Assuming customers want to do business on the Internet, where formerly they did it person-to-person, how does the person-to-person organization become an Internet organization?

Story: Becoming an IT Company

Is successful IT managed by goals or process? One e-commerce firm answered this question by focusing on “what's right for the customer”! While this has worked, what was not anticipated was the degree to which events overtook planning. In one quarter, Web hits tripled and the number of database transactions—customers looking for information—per financial transaction doubled.

In times of crisis, such as those caused by such usage increases, developers got customer service training and were put to work answering customer e-mail. More generally, software development and deployment management became pragmatic. For example, the critical requirement for any planned rollout of new functionality or capacity was the ability to roll back again if something went wrong. One result of a customer-centric ethic is a focus on “scale, scale, scale.” Avoided were distractions posed by “geewhiz” technology.

Management learned to take change as a given and to expect to reinvent themselves and their departments regularly. In such circumstances, employee retention and recruitment become essential. To make their recruiting more productive, managers developed a profile focusing on a candidate's ability to tolerate ambiguity, adapt to changing circumstances, and derive satisfaction from goal-defined success. Once such candidates were identified, they were paid whatever it took to get them. Spot awards were used at each management level to recognize and reward employees wherever and whenever outstanding performance warranted it.

To achieve high IT productivity in the face of burgeoning growth, management has to be willing to take risks and to create an environment that rewards good risk management. Inevitably, this means rewarding employees for things that don't work out, because they were the right things for them to try.

Question: How Can IT Be Managed in Health Care?

Physician compensation is driven by market forces, so why isn't compensation for health care IT professionals driven in the same way? Why do IT salaries not seem to be connected to performance in most health care enterprises?

Anyone who has tried to renew a prescription can see that communication is particularly unproductive in health care. How can health care reinvent itself to remedy this problem? Put differently, how can it do the simple things well? Unfortunately, health care IT rarely focuses on doing the simple things well, e.g., supporting master patient indexes and master provider indexes. Regardless, the need for constant evolution should be assumed, and health care IT personnel who can deal with this should be cultivated. Experiments should be tolerated, and both appropriate risk taking and success should be rewarded. And, of course, if a solution doesn't scale, some other important justification needs to be found for continuing the work.

Domain 8: An Applications Software Company

This example is based on an interview with the director of internal training at a post-IPO (initial public offering) enterprise application software company.

Question: How Does One Trade Off Software Timeliness and Quality-plus-Function?

While, in principle, a business is free to make short-term versus long-term tradeoffs as it sees fit, this doesn't mean that it's easy to make the right tradeoffs. Often software companies have to manage deep conflicts between those who want to make customers successful now and those who want to ensure the company's competitive position in the future.

Story: A Constant Battle within the Company and within Engineering

How does an organization both “get stuff out the door, now” and “ensure quality and competitiveness later”? Everyone agrees that both are important, but it seems hard to design an organization that can do both. Organizations seem to focus on one or the other, either as a permanent ethic or in alternating states.

Consider the following thought problem: “Classify software companies according to whether they get things out the door or produce quality.”

More specifically, how does an organization create an environment that can make these tradeoffs appropriately and in ways that strengthen the organization? Engineers might say, “If we take enough time to do x, we can scale without bound, and the competition will never catch us.” Sales, on the other hand, might say, “We haven't gotten a new product out the door in two years!”

Question: What Are the Parallels in Health Care?

We seem unable to learn from our mistakes in a way that makes the next release better. Instead, most health care IT projects either go nowhere initially or get deployed and then die later. Balancing short-term versus long-term objectives is difficult but critical. The fact that other domains may be “simpler” than health care doesn't seem to make this problem any easier to solve. There appears to be an intrinsic difficulty in making the appropriate tradeoffs; explicit recognition of this difficulty is an important first step.

Thesis

Health care can learn a lot from non-health-care IT—for example, solve the simple problems simply, make scaling a high priority, focus on data, and avoid trying to “boil the ocean.” I predict that the defining differences between health care and non-health-care IT will be self-extinguishing. Over time, health care IT and generic IT are going to become more and more alike. For one thing, everything is going to be on the Web. One way to benefit from lessons learned outside health care is to embrace external IT and focus on any emerging pragmatic differences, such as the paradoxic privacy requirements for health care information. (Health care information needs to be “private,” but it needs to be “used” in the patient's interests). In this way we can decide where health care has to be different in the near term and for how long these differences need to be sustained.