Brilliant idea … Too bad it doesn’t work

I just read an article that confirmed an impression that I have had for some time. I should warn my readers that this post is very self serving. I am a consultant whose job it is to help companies avoid the missteps detailed in this article. So, discussing this article is practically a personal advertisement. All I can say is that my comments are sincere.

Let me start with a quote from the review article: “crazy ideas that are physically impossible are raising huge sums … while great ideas that have huge potential are sitting by the wayside … Investment decisions are made for …ancillary reasons, like what the founders look like on YouTube videos … Meanwhile no one is doing the hour’s worth of basic math to see if their ideas have any legs.”

My late brother was a physicist. I used to very much enjoy listening to him explain why certain commonly held beliefs were unfounded or simply impossible. I remember hearing him once get into an argument with a philosopher who insisted that measurement was not the only way to determine existence. As a physicist, and as a religious Jew, my brother had no issue with believing in something you could not measure. But from a practical point of view, like when you’re trying to get atoms to behave in a certain way, the only rules that mattered were those that had been theorized and then tested and proven. After about 15 minutes, my brother gave up on the argument and simply walked away. That experience, though, taught me a critical lesson – reality is much more strict than people give it credit for.

Around the same time that  my brother was arguing with philosophers, I had begun to study magic. For a period of approximately 3 years, I developed a set of skills that let me make a coin vanish and a bottle flip upside down within a tight container. Although I never got into large-scale stage magic, I did read a great deal about it. It was from this experience that I came to the same basic conclusion as before – if it couldn’t happen “that way”, then it didn’t. I remember the first time I saw a famous magician make an airplane vanish. Strangely, I was not amazed by the magical component, but rather was impressed by the engineering. It was clear that there were only two options: either the plane was never there in the first place, or the plane was still there but could not be seen. Exactly how this would be done was a question for a stage engineer, rather than Merlin.

When I studied computer science [before medicine], I also came to realize that there was no “magic” in getting a computer to do what you wanted. You had to give the computer very specific instructions, which the computer followed to the letter. I appreciate that these days, we talk about thinking computers and systems that seem to exceed the capabilities that they were programmed to have. But ultimately, if a human possessed the mental power of a computer, he or she could track through the code and find the reason for the given behavior.

This realization about software has been critical in my work with physicians. In a previous post, I described a case where a physician asked the programmer for a tool that compared the present diagnosis to “similar diagnoses”. This concept, which is logically very simple, is in fact an involved piece of coding. It requires creating a dictionary whereby each diagnosis  is associated with a series of terms that are equivalent in nature. The trickier part is that the same diagnosis could be considered similar to two or more different types of diseases. So a pneumonia is similar to other infectious diseases but it is also similar to other diseases of the lungs. Therefore, when the physician makes the innocent statement of having a program find “similar diagnoses”, this requires a great deal of planning, data entry and very specific decisions about how diagnoses will be classified.

When I explained all of this back to the physician, he looked at me strangely. He truly could not understand why such a basic medical concept was so difficult for the computer. In his mind, if a computer could do the calculations for sending a man to the moon, how could it be that generating a list of similar diseases could be so hard. I actually did try to explain the issue to this physician, but he shrugged and said that he did not understand computers and that thankfully he did not have to.

It struck me at that moment, that had I not been there, the exchange would have been between the physician and a non-medically trained software developer. And I suspect that the content of that exchange would have been similar to the famous “who’s on first” routine. Although both the developer and physician would be highly educated and intelligent individuals, they would be using totally different language for the same concepts. The developer would have become frustrated over the fact that the doctor could not understand something as basic as specifying descriptive properties for a diagnosis [in order to compare it to other diagnoses] and the doctor would have become frustrated over the fact that he had to deal with such details. From the doctor’s point of view, his role in the “design” of the software would have been simply to state what he wanted it to do, without any consideration as to how his requests would be implemented.

During the time that I was developing the core portions of my electronic medical record, I was very aware of the fact that the process would have taken much much longer, if I personally did not understand both the doctors’ needs and the computers’ capabilities. In fact, what happens far too often is that the doctors simply provide a list of data fields that they will require for recording an assessment, and the programmers throw these fields onto a digital form without any real attention to their location on the form and the resulting workflow. This is why you will hear doctors say that recording basic information can require navigating through multiple forms. While it might make sense to have all of the kidney related fields on one form and all of the heart related fields on another, this compartmentalization does not necessarily match the presentation of a disease, or the way in which doctors work. It truly is astounding how such design issues can make medical software incredibly frustrating to use as well as terribly inefficient.

I am extremely and uniquely fortunate to have had the experiences I have had. I understand the very analog nature of medicine, while still appreciating the need to define elements well enough so that they can be broken down into blocks that have only zeros and ones on them. Translating nonspecific but valuable ideas into efficient software was critical to the success of the projects I worked on. Now, when I consult for an investor, I translate the details of a programmatic solution (whose developers are asking for funds) into a simple story that clearly describes the purpose of the software. By being a liaison between two very different worldviews, I can help projects succeed where they would have otherwise failed.

Thanks for listening



About the Author
Dr. Nahum Kovalski received his bachelor's of science in computer science and his medical degree in Canada. He came to Israel in 1991 and married his wife of 22 years in 1992. He has 3 amazing children and has lived in Jerusalem since making Aliyah. Dr. Kovalski was with TEREM Emergency Medical Services for 21 years until June of 2014, and is now a private consultant on medicine and technology.
Related Topics
Related Posts