Medical Informatics Challenges of the 1990s

Medical informatics is in the midst of deep secular changes. In hindsight, these changes have been operating throughout the 1990s; they show no signs of abating.

A simple exercise will demonstrate that these changes are not yet widely acknowledged in our field. Before you read further, please free associate in response to the following phrases, and then compare your associations with those below:

• Software in the 1990s

• Health Care Computing in the 1990s

• Medical Informatics in the 1990s

My associations when I hear “Software in the 1990s” are as follows:

The first thing I think of is SCALE. Prior to the 1990s, it was not at all clear how anything in computing was going to scale—e.g., how it was going to be accessed by the majority of computer users. As of 1997, we are starting to take the Internet, Web browsers, and Web search engines for granted. Web search engines are particularly dramatic; whatever their shortcomings, the fact that several systems independently index the World Wide Web (WWW) on a more or less daily basis was not anticipated.

After scale, my next association with “Software in the 1990s” is GLOBALIZATION. One can now buy software that is used productively around the world by users who know only their native languages. The economic incentives are clear. If a software product can be used worldwide, it is easier to justify investing in its development, maintenance, and enhancement than if that same product could only be used by one country or by users of one language.

My third “Software in the 1990s” association was easier to foresee: namely, it is TOUGH TO SURVIVE AS A NICHE. Microeconomic theory predicts that new markets can support many suppliers of products that serve a given need (e.g., word processing); however, as those markets mature, only a few of the companies survive, and starting a new software company at that point becomes a high-risk venture. Success often means a buyout by a larger company. Additionally, markets tend to migrate toward so-called total solutions, further decreasing the number of software “niches” available.

The associations above were driven largely by events larger than health care. A different set of associations are relevant to “Health care computing in the 1990s.” These can be expressed as specific observations.

First, the most obvious observation is that most of health care computing is now driven by the NEED TO SURVIVE AND COMPETE. Many health care enterprises are at risk of going out of business, and for those enterprises that survive the reward is stiff competition. Thus, it is not surprising that the acquisition and deployment of health care information technology are driven by these needs. While improving the quality of care and reducing costs are certainly aids to competitiveness, most health care enterprises first need to understand where their resources are being consumed and what it will cost to compete in a given market. In light of these observations, questions such as, “What will compel physicians to use computers?” are off center. Questions that are on center include, “How do we create and leverage comparable patient descriptions?”

The second observation that comes to mind is that most health care computing in the 1990s is VENDOR SUPPLIED. Few health care enterprises have the expertise and the capital to develop their own software; instead, they must invest considerable effort to choose from a large number of vendors, all of whom claim that they can fulfill the needs of the enterprise. The good news is that, potentially, enterprises can benefit from economies of scale in a way that would be impossible if software were produced internally; however, it is not clear yet that commercial software offers such benefits. Instead, many vendors still offer relatively closed and mostly proprietary solutions. This raises the often repeated question, “How should our field deal with the vendor community?”

The third observation is that health care computing in the 1990s is a FRAGMENTED MARKET. The market-leading vendors still have only a small fraction of the market, and much of their share has been obtained by purchasing other companies instead of by developing better or more comprehensive products. This makes the vendor selection process more difficult if only because there are so many of them. While in theory this means that health care enterprises could operate in a buyer's market, this does not seem to be true in practice. The questions for our field are, “Are these observations intrinsic for the foreseeable future, or are they temporary? Are they good or bad?”

So what about associations with “Medical Informatics in the 1990s”?

First and foremost is the EMERGENCE OF DATA STANDARDS—HL/7, LOINC, and others—which have enabled successful intraenterprise interoperability. Our field gets part of the credit for both creating and deploying these standards. Just as the programming language C became the default means of software portability, various message standards developed for specialized purposes in the context of laboratory tests or imaging are now the means to portability of patient data and biomedical information.

Second is the EMERGENCE OF THE INTRANET as the default standard for client-server deployments. While it was generally acknowledged that supporting thousands of workstation desktops in a health care enterprise was prohibitively expensive, few anticipated that the simple power and robustness of the Intranet solution to the desktop problem would dominate distributed access to patient information. As with the other associations noted above, that fact that the Intranet is scalable, maintainable, and relatively inexpensive overcame the technical shortcomings inherent in the approach.

Third is the LACK OF SCALABILITY OF SOFTWARE produced by our field. Engineers sometimes sacrifice functionality to achieve scalability; in certain contexts software that is not scalable is not real. Medical informatics' focus on functionality often neglects scalability; in the 1990s this may impede deployment.

Fourth is a long-standing trend that has gotten worse during the 1990s—namely, a COLLECTIVE NEUROSIS REGARDING SOFTWARE REUSE. We have all observed Hospital B reject software in use at Hospital A because it's not perfect or because “that's not the way we do things here.” While the issues behind such rejections may be complex, there is no denying that little effort is expended in identifying those portions of health care information technology that could become commodities and those that might support principled differences between health care enterprises.

Fifth is an INABILITY TO LEARN FROM OTHER FIELDS. If only because, for all the reasons mentioned above, health care cannot operate alone, medical informatics needs to learn from other fields. We are not the only ones who struggle to use information technology effectively; whatever the ways in which we are different, we should be acknowledging the ways in which we are the same so as to gain economies of scale to tackle the problems that only we know how to solve.

Finally, more than ever before, there is a now a NEED FOR MEDICAL INFORMATICS. The question is, “Will we fill it?”

First, we must adopt standards and technology that larger markets (e.g., business and entertainment) have made inexpensive. What software should be adopted from outside health care, and what should be developed especially for health care? For example, health care computing may have special needs for security and privacy that do not appear to be supported by other markets. And it is unlikely that other fields will help us with content (sematic) standards.

Second, medical informatics should continue to lead the health care computing industry in the direction of OPEN, HETEROGENEOUS, AND STANDARDS-BASED solutions. The one dimension where buyers seem to have leverage is interoperability.

Third, we should develop solutions that scale. If it is difficult to get information technology to be used productively in one hospital, it will be much more difficult in the multi-hospital, geographically distributed health care enterprises that are emerging.

Fourth, medical informatics should define reference architectures. For example, there is no as yet widely accepted default architecture for computer-based patient records. Such a default might indicate whether patient descriptions should be stored in a single archive, or in distributed form (e.g., where the descriptions originate). Architecture is a tool that enables infrastructure to be assembled from reusable components. Leadership in this regard from our field might have a dramatic influence on progress.

Fifth, your associations may imply additional but consonant imperatives.

In summary, we should recognize the need for a shift in the balance of software trade—namely, HEAVY IMPORT, LITTLE EXPORT. In contrast to the situation in the 1960s when the medical applications of computing were cutting edge and both ideas and software were exported to other fields, the 1990s finds us in the position of importers who attempt to integrate and leverage software produced outside the field. Because of the aforementioned economies of scale, this trend is not bad. Acknowledging it may help us decide where we need to focus our resource-limited research and development efforts.