The rapid pace of technological change and its implications is something that I have addressed here many times. But equally challenging is the slow pace of technological change, and this has significant challenges for the business leader.
I had lunch with an old friend, Bob Abarbanel, and we talked about his latest work. He is now a scientist at GE Medical Systems, developing a doctor’s diagnostic system that could revolutionize the practice of medicine.
We have all visited a doctor’s office and watched as our vital signs were checked, lab work was done, questions asked, and then the doctor says, “This is what I think is going on.” How do they do that? Years of training and experience have allowed them to translate symptoms into probable cause, probable cause into further tests, and test results into a diagnosis. Bob’s team is working a computer system to capture all of these symptoms and vital signs and produce suggested further tests and probable diagnosis.
The Need for a Medical Diagnostic System
It seems like a perfect application for computing technology, and medical leaders seem to agree.
“Widespread use of clinical decision support, enhancing the computerized patient record and interactively provided at the point of care, has been an abiding vision of clinical informatics for three decades. This goal has been enunciated authoritatively by the Institute of Medicine and is central to national initiatives in medical error reduction,” according to the paper, “The SAGE Guideline Model: A Knowledge Representation Framework for Encoding Interoperable Clinical Practice Guidelines,” written by many authors with work funded by the National Institute for Standards and Technology (NIST).
Such products could sharpen diagnosis, narrow likely causes, reduce errors, and speed the recovery process. Sounds great. And it sounds like the replay of a plan from the early 1980s. It also sounds like the fulfillment of a promise of the 1950s. In spite of the progress of this research, products may or may not emerge as a result of this work. Why is this taking so long?
Why Does It Take So Long?
The challenges of building such a system that will work in a real environment are great. Yes, it has been possible for some time to be able to draw inferences from patient data. But the path from being able to do these logical steps to creating a tool that will really help a doctor are long and difficult, mostly involving “under the cover” details.
“The reasons for this failure are manifold, but have been identified by leaders in informatics to include: lack of agreement on a sharable model for representation and execution, non-integration of decision technology with comprehensive computerized patient record data, paucity of information-based intervention modes in support of guideline recommendations and lack of integration with the local clinical workflow model,” ibid
The authors are saying that a successful product must help the doctor in the natural way he or she works. A product will be resisted if it adds lots of steps to diagnosis by requiring extra data entry, awkward access to patient records, and difficult connections to the diagnostic rules and other shared knowledge. Addressing these issues is vital for two reasons: First, medical professionals, like the rest of us, resist change, particularly when it adds to the workload; second, cost pressures in the medical field will require demonstration of the “business value” of such tools, while more time by the medical professional adds to the cost.
There is another family of reasons why there is such a long path between the dream and reality of such technology systems. Many of these “expert systems” grew out of the artificial intelligence branch of computer science, inspired by computer science pioneer Alan Turing’s 1950 paper, “Computing Machinery and Intelligence.” For technologists, the goal was to demonstrate “thinking” by the computer. So an early idea was that such systems could replace the human being and automate the diagnosis process. While it is interesting intellectually to see how far such research can go, few people are prepared to put their lives in the hands of such a system. Some of the work of Abarbanel’s team is to have the system support the doctor in decision making, rather than make the decision. They also are concerned with producing a decision record on how the conclusion was reached. So when doctors draw on the information of the system, they know not only the conclusion, but can also review the steps that led to the conclusion.
This is a common step as technology reaches a useful state. The technologist envisions one result, but the final product does something else. This has happened repeatedly in technology development. The original idea for the ATM was to shorten lines inside the bank, not to create 24-hour banking. The VCR was to produce video for major news stations, not to show movies at home. So the early dreams, even the current dreams, for medical diagnostic systems may look quite different when they are widely deployed.
Another challenge from this slow process is the memory of people who have been burned by the premature rollout of a new system. One of the reasons some of the problems of medical diagnostic systems are now being addressed is because computers are more powerful, networks are faster, and data storage has dramatically dropped in price over the years. But someone with a bad experience 10 years ago may not know that this is “different.”
Finally, there are the questions of unintended consequences. What happens when the diagnostic system makes a mistake, or is deliberately sabotaged? What happens when medical records are so well standardized and accessible that others can break into such systems? None of these provide reasons to not create such systems. But they do provide challenges to the innovators that must be honestly confronted.
The Challenge for Leaders
There are many implications of this slow path from concept to practice. One of the biggest is the significant challenge it creates for the business leader.
According to Max DePree in his book Leadership Is an Art,
“The first responsibility of a leader is to define reality. The last is to say thank you. In between the two, the leader is a servant.”
But how does a leader define reality when it comes to technology? I was in a discussion with a faculty colleague recently, looking at the article by Prabhu Guptara in the last issue of Ethix with its promise of service robots. In his article, Guptara discussed the prototype service robots in Japan, including the receptionist that can speak four languages and make small talk about the weather. These could be on the market in seven to 10 years, he said. But my colleague’s reaction was, so what? We’ve heard about this for a long time.
Almost 10 years ago, I was in the office of my new boss at Boeing after the merger with McDonnel Douglas, explaining what my organization did. I was telling him about an application we had built called Fly-Thru, enabling an engineer to go through an airplane based on its electronic parts descriptions, looking at clearances, how parts fit together, potential for maintenance, etc., all before a single part had been built. Incidentally, the same Bob Abarbanel who I referenced earlier was a major contributor to the development of this application. My boss’s reaction was, “We already have this capability.” I knew that was not possible, but it took significant investigation to determine he had seen a demo from a vendor for a product that could do a fraction of what our tool could do, and only on very small problems.
There is a major challenge for the technologist as well. To get funding for a new project, it is necessary to build the business case. The technologist must rightly respond to the question of why the company should make a particular investment. A real scientist will be very careful not to over promise. But the more a technologist drifts into a marketing role, the fuzzier the line becomes in drifting from “what could be possible” to “what will happen.” Often, the funding goes to the one who makes the biggest promise.
The details matter, and the details are difficult to understand. The larger and more technically complex the project becomes, the greater is the need for both understanding and trust in the relationship between the leader and those who know technology.
A fascinating documentation of this is found in the book Megaprojects and Risk: An Anatomy of Ambition, by , Bent Flyybjerg, Nils Bruzelius, and Werner Rothengatter. Major projects — from the Chunnel to rapid transit systems to complex bridges — all fell far short of the “business benefits” promised at the beginning of the project.
Users of new systems are caught in a difficult spot. It is usually easier to keep doing things as they used to be done than to learn a new system and change. For this reason, users generally resist new systems unless they are very simple to use and overcome a difficulty the user has been struggling with. Another challenge for the leader is to know the difference between the natural resistance from the user, and the real issues underlying that resistance that should be heard and dealt with? We saw from the medical diagnostic system that there are some very important “details” that must be addressed.
Conclusion
Many of my colleagues in business want to leave technology for the “techies.” They don’t want to engage in the messiness of details that they believe are unnecessary. But unfortunately, the details matter. The wise leader will know the difference between resistance to change and a bad system. The wise leader will understand both the potential upsides to the new system and the potential downsides. The wise leader will know when a system is not ready to be deployed and will save lots of grief, and when it is time to deploy and gain competitive advantage. As technology encroaches further into all aspects of business, it will take a new kind of leader to “define reality.”
Al Erisman is executive editor of Ethix, which he co-founded in 1998. He spent 32 years at The Boeing Company, the last 11 as director of technology. He was selected as a senior technical fellow of The Boeing Company in 1990, and received his Ph.D. in applied mathematics from Iowa State University.