Medgadget Series on the Differences and Similarities between Scientists, Engineers, and Physicians.
The 3 Types:
The Physician: MDs are trained in medical school to think about differentials and categories. A patient’s presenting signs and symptoms are processed, then historical information is used to determine the most common diagnosis associated with that data set. More complicated tests are given based on the most common and most dangerous diagnoses, and then treatment is often based on the outcomes of those tests. This is a categorical approach to problem solving. The MD tries to determine what category the patient belongs in, and then treatment is based on the assigned category. This is a very efficient system when a patient has a problem that has been encountered before and a pre-existing data-set that the patient can be matched too. Often, a complete picture isn’t even needed since this problem solving approach is based on probabilities. However, when the patient has something not seen before, this is a very inefficient way of treating the problem, as the MD moves to less and less common solutions. Programmers would call this searching a known set, which is often the fastest way to find a solution if the solution is in the set, but it is the slowest if the solution is not, as all possibilities have to be excluded before determining that the answer isn’t there.
The Scientist: In contrast to the MD, the Scientist is trained to look at a problem in the abstract and use testable hypotheses to isolate all the component parts of a problem and solve them (individually, if possible) in a logical way . Breaking down the problem into its component parts can determine the independent root causes. Then, using those root causes, the Scientist can arrive at a solution to the overall problem. Solving problems in this way is more resource- and time-intensive than the Physician method, but if the right hypotheses are posed, this system can handle a broader range of problems and generate new data that are applicable to other problems. Programmers would call this a global search, which is often the least efficient way to find a solution, but the solution found would have a higher chance of being the optimal solution because it ideally takes into account the most information .
The Engineer: One way to think of the Engineer’s method is as a hybrid of the Scientist’s and Physician’s methods. The Scientist starts with a new set of hypotheses for each problem, and the Physician starts with a set of solutions that can be applied. The Engineer is trained to take a known solution and then use that as a starting point to hypothesize a solution that applies to the problem. Thus, the Engineer’s approach is also a combination of the advantages and disadvantages of the above methods. Like the Scientist, the Engineer tries to break down the problem, but doesn’t break it down all the way. Since the Engineer isn’t looking for a root cause, the problem is only simplified enough to get a solution that works with the least amount of change from the current paradigm. Going back to our programming analogy, this is a local search: again, a hybrid of the two above examples.
This post continues along the problem solving timeline and discusses how the different archetypes respond to unexpected data or failure. While similar to problem-solving failure analysis is more of an introspective skill set that entails a different set of biases. Something possibly went wrong, and the task is to find the error, adding a dimension of responsibility that the discussion of problem solving in the previous post doesn’t necessarily address. Also, presenting at the meetings described below is a potential outcome being considered in many people’s mind when contemplating a new idea. How are they going to defend this decision if things don’t go well? And in what environment are they defending it?
The title of a symposium a few months ago at Beth Israel Deaconess Medical Center in Boston, MA was “Opportunities and Challenges in Surgical Robotics,” but really it was a day devoted to getting academic engineers and practicing surgeons into a room and figuring out what projects they could work on together. All of the participants were eager to find ways to work together, but I noticed that often the two groups were not operating in the same mindset, something that I see a lot when MDs and engineers collaborate.
Lawyers are involved in both successful and unsuccessful medical technology projects, with a lot of frustration arising from the lack of knowledge by non-Lawyers about the legal world. Even apart from the differing experiences of people involved I think some of this lack of understanding comes from the very different ways each group was trained to solve problems and even how each group formulates problems themselves.