Recently, a colleague submitted a request for a new computerized tool, to be added to the existing electronic medical record in my former company. One of the specifications for this valuable tool was that the computer should exclude all cases where the final diagnosis was similar to the diagnosis of the present case being managed.
This innocuous sounding request is actually a perfect example of the need to translate the requests and thought processes of physicians into a structure that computer programmers can understand and then implement.
When a doctor says “similar diseases”, the doctor himself is clear on his intent. More so, most other doctors would also be clear on his intent. But when programming a regular computer system [i.e. one that does not have high level artificial intelligence built in], such a statement must be broken down and fully clarified before progressing.
Let’s take the diagnosis of pneumonia as an example. When the doctor says “similar” diseases, does he mean similar in terms of an infection? If so, then similar diseases would include ear infections, skin infections, and even the notorious meningitis. However, if similar refers to the location of the disease process, then the doctor was actually referring to diseases like pulmonary edema [fluid on the lungs], asthma and severe inflammation [not infection] of the lungs. Most likely, what the doctor was thinking of was some kind of mix of these two types of diseases.
How is the computer meant to know what the doctor intended? The answer is, that the computer cannot know. What this means in practical terms is that the physician will need to specify for each type of disease, a list of other diseases that are considered “similar” to the primary disease. Do you think every doctor will agree on what diseases are similar to other diseases? I can promise you that given the opportunity, there would be a huge fight and disagreement over what constitutes similarity amongst diseases.
Nevertheless, someone has to decide. So, you pick one senior doctor who will be responsible for building this list of similar diseases. This will be a long and tedious process. The best way to do it is to build a special tool that allows the doctor to easily match up the primary disease to all of the similar ones. The work could definitely be split up amongst multiple physicians, all using the newly developed editor to create these similar lists.
Once you have a table that includes the primary diagnosis and the list of matching diagnoses, then you can proceed to write a program that looks for similar diseases amongst all charts, based on this new table that you have created.
The purpose of this story is to demonstrate the fundamental difference between what people, physician and nonphysician, will say versus what they mean. The human language is a beautiful device that can express a thought that triggers a whole mental process. So when one human says to another human, the term “similar”, our brains are nearly immediately able to understand the term and to extract a list of similar items.
Once a computer understands the term “similar”last visit the, it can also extract the data in a fraction of a second. But we are still at a point where we must explain such concepts to the computer. In this example, a physician must tediously build a table of similar items for each diagnosis, in order for the computer to be able to later retrieve this list and use it for various statistics and immediate clinical assistance.
In my experience, doctors will often use such human terms without a second thought. When the same doctors are approached by the programmer for further clarification, the doctors may find themselves tongue-tied. And I have seen it happen that two well educated professionals can speak to each other, without the other really understanding what the intention of the request was.
Thankfully, because of my dual training in medicine and computer science, I have been able to translate such requests from the physician into a solution that the programmer naturally understood and could quickly implement. Many times I was both the physician making the request [based on my experience with my own software] and the programmer who implemented the new functionality. The fact that there was no need for one side of my brain to explain concepts to the other side of my brain, saved a tremendous amount of time and helped avoid many a misunderstanding.
In one of the online lectures I was recently listening to, the speaker made a very strong argument in favor of learning multiple specialties. Whereas once upon a time, a high school degree was considered a guarantee for employment, then came the age when a university degree was a minimum requirement for any decent job. Now, there are those that argue that having only one area of expertise limits a person dramatically. So whether it is computer science and medicine, or psychology and an MBA, having formally studied two different specialties, makes you all the more interesting to potential employers. And once you have these multiple specialties, you will find that your ability to translate concepts back and forth between the two topics, has special value to many others. Of course, studying two specialties will extend your education, perhaps even by a number of years. But in our new reality of young people having a life expectancy of 80 more years, it is all right if an extra couple of years is spent solidifying your skill set. I would go farther than this and say that people will need to become accustomed to changing tracks and learning new sets of skills, relatively late into their professional lives. The world is changing so quickly that 2 to 3 decades is enough for a total revolution in many spheres. So it may very well be, even for the highest educated person, that a great deal of their knowledge will become obsolete halfway through their career and thus they will have to retrain themselves entirely.
I don’t think it should surprise anyone that, in my perspective, the role of the technology department in a company is so critical, that at times it may even surpass the value of the medical staff and its infrastructure. This does not mean that, at least in the present day, a medical service can function without physicians. What it does mean, is that your information technology department [which handles all the software and hardware and networking and servers for the company] deserves a great deal of respect, and perhaps more importantly, requires a significant amount of resources to do its work. You can spend your money on the top medical staff available. But if you still have on staff any physician who is less experienced and less confident, then the need for a digital chart and real time online consulting becomes even more critical. Without such a consulting system, a young doctor working in the middle of the night can easily find himself being forced to make a decision without the proper expertise. And while it is true that the same young doctor could pick up the phone and discuss the case with a senior physician at home, it still remains difficult to offer solid advice when you cannot see the patient or the x-rays or the cardiogram or the throat and ear of the patient. I am more than willing to compromise and say that both the medical and technology sides of a medical service are equally critical to the success of the service.
Unfortunately, I have read too many cases where the IT department is taken for granted and effectively neglected. Eventually, such a company will falter. I hope as this time goes by, there will be a recognition of the fact that in the new world of medicine there must be a strong collaboration between the technology experts and the physicians. When this does happen, you see tremendous results. But when a CEO thinks he can save money by reducing the investment in IT, the negative effect of such a move will soon become evident.
I would very much like to hear other people’s stories related to technology and medicine. I welcome all opinions, for and against my viewpoint. We need to discuss this. If we do not, then we will likely miss critical opportunities, and that would be unfortunate.
Thanks for listening