The application of future technologies to medical informatics - Medical Informatics

Physician Executive, Jan, 1994 by David S. Greenberg

The ability to embed a voice or image object inside a document or database is another technology with near-term applicability. Note that neither voice nor image are legitimate data elements, in that neither can be sorted or queried in a truly elemental form. However, until the dictation is transcribed, the voice object can be easily accessed, and the availability of scanned images within the database serves as an interim step until each data source is available in true electronic form. Storing voice as an object is a more realistic mid-term approach than holding out for the Holy Grail of "voice recognition"--where the computer turns voice into typed text.

New technologies follow a well-defined time progression, from early concepts, to market acceptance, and, eventually, to obsolescence. For some technologies, the gestation period can be quite long, with development of a mass market always just around the corner. Voice recognition is a good example of such a technology. Others arrive and take off with a bang, such as the Intel 486 processor. For every new technology that has not yet hit its stride, there are limited-market products available to those willing to take the risk and blaze the trail. However, these early products tend to be incredibly expensive, proprietary, and more likely to become obsolete as soon as the real market for the technology takes off. In addition to the obvious cost implications of jumping into a technology too early, there is the additional problem of limited support for development. Whether it's a new wireless network product or new software development language, if you are early you will have to solve all the problems yourself.

There is nothing inherent in the needs of medical informatics that demands technologies that are not yet ready for prime time. The development and deployment of workable clinical information systems are more a matter of engineering than science and can thus be accomplished by reduction to practice of state-of-the-art technologies that have reached the stage of moderate market acceptance. Unfortunately, finding this "sweet spot" in the technology time line is a bit like playing the stock market--invest too soon, and you may pick a loser; invest too late, and it may be obsolete.

In order for computers to become a ubiquitous part of health care, we need to spend less time telling them how to do what we want them to do, and more time telling them what we want them to do. Fortunately, we're moving in this direction. In this regard, every large health care organization needs to develop internal resources to build or customize its own applications. The more you build yourself, the less you will have to mold your processes to a vendor's preconceived notions of how you ought to work.

A funny thing happens to software vendors. In order to convince you that they have the right product for you, they have to come in as the experts. They forfeit the ability to sit down with you and say, "Gee, I really don't understand what you want to do here. Please explain it to me." To do so would be a sign that they lack the knowledge and experience you expect from your vendor. Granted, there are certain business processes that require standard definitions across all organizations, but the local needs and customs must be acknowledged for software to gain acceptance and offer value.