How Physicians, Engineers, and Scientists Approach Problems Differently

How Physicians, Engineers, and Scientists Approach Problems Differently

IDEAS fosters and provides an interactive forum for innovation at the interface of surgery and other disciplines—whether the social, biological, or physical sciences—with the goal of improving the lives of patients worldwide.

Watch the IDEAS Surgical Robotics symposium 2012.

Upcoming Event: The next IDEAS symposium will take place on Saturday, April 27, 2013. Please check back later for details.

Medgadget editor Dan Buckland is in training to become a physician while trying to remain an engineer. Here he talks about a recent symposium he attended that was at the intersection of surgery and engineering.

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.

The surgeons were looking for better ways to do tasks using skills they already had, while the engineers were offering different skills that would (hopefully) accomplish the same tasks. As an example, the surgeons were asking to replicate open surgical techniques in a minimally invasive procedure using surgical robots, while the engineers were saying that using robots would allow procedures that had no open case correlates. This subtle difference in expectations of progress is due to many things. Engineers have to realize that the current decision makers (senior surgeons) on the clinical side of R&D were trained to do things a certain way, that they do very well and have been shown to have very good outcomes. Senior surgeons often want to know that new technologies can operate in the same workflow they are comfortable with and that there is always a failure mode that allows them to use their existing well-honed skill-set to fix any problems. Residents and junior surgeons will often be more comfortable with newer technologies, but they often won’t adopt them without support from the senior partners in a group or senior faculty in an academic medical practice. It follows that engineers will have to design and convince two sets of end users: the senior and junior surgeons, both groups of whom are concerned with how new technologies will fail them, but with two different mindsets.

In the other direction, surgeons should realize that when they go looking for an academic engineer to solve a problem, that engineers don’t think in terms of differentials and that they are not going to automatically accept that the surgeons’ way of doing things is optimal. Often, the best way to pose a problem to an engineer is to follow this rough guide:

1. Context

Who are the patients? What are the steps the entire task entails? Are you trying to give 80 year old females new knees, but they will still have the bone density and cardiovascular system of an 80 yr old? This could impact the operational envelop the engineer is designing for. Maybe endurance is more important than maximum failure load.

2. Deficiency in current procedures or tools as the surgeon understands them.

What exactly doesn’t work in the way you feel it should? Note: this doesn’t mean the surgeon needs to know the solution already, just how to describe what is wrong. Does the endoscopic stapler you use work perfectly fine, except you don’t get any tactile feedback if it is not properly engaged? Is the display positioned in a way that your thumb is always over it the moment you need to see it? Does it take 30 seconds to reload a device that you need to use once every 10 seconds?

3. Ideal outcome (both in terms of overall patient outcome and narrowly focused to the problem itself)

In the best of all worlds, what do you hope the solving of this problem will change? Does it make a 4 hr procedure a 1 hr procedure with minimal direct change in morbidity and mortality? Does it lessen surgeon fatigue with no patient impact? Does it reduce a 30% chance of failure/infection to a 20% chance? This can help set everyone’s expectations to the same level.

4. Limitations and constraints to possible solutions

In your experience, why has this problem not been fixed already? Do you know what has been tried in the past and why it didn’t work? Are there other users of this device who will be impacted by this change? This can prevent work being re-done if it doesn’t have to be. However, sometimes the work does have to be re-done, but in a different way, so be sure not to close off a route to a possible solution by simply stating “We already tried that.” without explaining that attempt.

5. Explanation as to why the current way of doing things became the way things are done

Why was the display/trigger/grip/etc.. put in that position in the first place? Why does the EMR ask for a patient’s weight before it will let you prescribe the drug?

All this may seem like common sense, and to others it might seem like overkill, but it really will make the problem clearer for all involved.

This gulf in communication is not limited to engineers and surgeons. What may be unique in this case is thatt much of the difference in thinking strategies is a function of how engineers and physicians are trained. From my perspective as a US trained engineer and medical student; engineers learn to always approach a problem from first principles, whereas physicians are trained to see problems from a categorical view. (I plan on writing a more thorough post on this concept in the near future).

It is frustrating to see two groups of experts talk past each other routinely, when they both have similar goals and don’t realize that the path is not agreed on. Hopefully, meetings like the IDEAS group will continue to involve both communities and keep them talking to each other through the development process.

Medgadget editor Dan Buckland is in training to become a physician while trying to remain an engineer. Here he talks about how his training in different thinking styles leads to different problem solving strategies.

In my last post, I mentioned that I thought that a lot of the miscommunications between Surgeons and Engineers were due to the differing ways that they approach problems. More than a personality difference, Physicians [1] and Engineers are trained with different philosophies of problem solving. Scientists are another group that is often mentioned in the same breath as Physicians and Engineers, and they are trained in a third, different way as well [2]. With this article I’ll explore these differences, and also discuss three example problems that characterize these three different ways of thinking. These three types of problem solvers (Scientist, Engineer, Physician) are meant as archetypes representing the training methods each field is known for. Of course, an individual would use a mix of these problem solving methods based on their knowledge and experience, but they may never have received formal training in methods other than the ones they are expert in. These simplistic descriptions are not meant to imply that all people in each of the described groups are only one way or that they are incapable of seeing things another way. (For more caveats please also see my footnotes at the end.)

divider How Physicians, Engineers, and Scientists Approach Problems Differently 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 [3]. 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 [4].

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.

divider How Physicians, Engineers, and Scientists Approach Problems Differently

Three Approaches to Three Problems:

In this section, I will lay out a problem and describe how the three archetypes above would approach solving the problem. These are not random problems, each one is meant to show that none of the problem solving types is inherently better than the others, but that they are each better suited to different situations.

Patient A started coughing this morning, what should she do about it?

Physician: What are the top 5 reasons people cough? Has she been treated successfully for a cough in the past? For this patient’s age and medical history, which of those 5 causes are most likely? Would any test results change the treatment plan? Treatment will be based on what has historically worked best for the most likely diagnosis.

Scientist: What would cause this patient’s particular cough? What is the root cause of her lung or throat irritation? If it is infectious, what is causing the infection? If we find what is causing the infection, do we know how it is causing the cough or irritation?

Engineer: What is different now than when she wasn’t coughing? What was she doing this morning when the cough started? If she tries one treatment and gets a little better, then she should use more of it to get a greater effect.

In this case, the Physician probably has the fastest and most efficient route to diagnosis and treatment plan if there is a common cause for the cough. The Scientist’s method, when it eventually gets to a treatment, will have produced a lot of information, but it will take a longer time and be very resource intensive. However, if there is a uncommon cause for the cough, the Scientist method will be more likely to find it. The Engineer’s method could work as well, but doesn’t use the shortcuts of the Physician or the robust strategy of the Scientist.

Patients B,C, D, E, and F all have a form of slow growing cancer no one has seen before. They are all related, but the inheritance pattern is not one that has been observed in other cancers. What should be done?

Physician: Of all the cancer types known, which one is the closest to this one? How is that cancer treated? If that doesn’t work, what is the next closest match? How is that one treated?

Scientist: How does this cancer work? What is the cell type involved? What makes the cancerous versions of that cell type different than the non-cancerous versions? Is that difference something that can be detected in this patient? Can that information be used to determine how to kill just the rapidly growing version of that cell type and leave the rest alone?

Engineer: What makes this cancer different than the closest match that has been treated in the past? Can we use that difference to modify the treatment plan?

In this case the Scientist’s method is probably the best approach to take, since the problem itself has very little known about it. The Physician method will get to a treatment quicker, but is likely a shot in the dark and may cause more pain and discomfort with less overall benefit if the closest guess has a very different root cause. The Engineer method looks at these differences to try to get to a solution.

Patient G had her gallbladder removed by Dr. H. Dr. Hn performs the procedure laparoscopically, but the tools she uses don’t work the way she wants them to, and she feels that she spends too much time struggling with the equipment rather than doing the procedure. Other surgeons say they have the same problem too. What should be done?

Physician: What have other surgeons done to compensate for the unwieldy tools? Do any of those methods fix the problem of taking too much time struggling with equipment?

Scientist: How would we design a brand new laparoscopic system that doesn’t have those problems?

Engineer: What exactly does the surgeon like and dislike about the system. How could we modify the current system to keep the benefits and lose the difficulties?

For this issue the Engineer probably has the best approach. Rather than starting from scratch like the Scientist, or treating the problem as fixed like the Physician, the Engineer’s approach looks for the simplest novel solution using the current context. divider How Physicians, Engineers, and Scientists Approach Problems Differently


A better understanding of the problem solving methods of others can go a long way in improving communication. A common response on Twitter to my last article was that a lot of communication problems could be solved by just putting everyone in the same room together. While that might work, anyone who has gone through MBTI training of some sort knows that is really just a new way to start conflict unless there exists an understanding that the other people in the room don’t think and respond the same way as you. The three archetypes detailed in this post don’t break down neatly within the MBTI categories, though some similarities exist. In a future post I will discuss other ideas for improving communication between these groups

While this simple breakdown leaves a lot to be detailed, hopefully it is a step in the right direction that allows people from different fields to work together more efficiently.

divider How Physicians, Engineers, and Scientists Approach Problems Differently


[1] For the purposes of this post I am grouping Surgeons and Physicians into a single group. All MDs went through the same 4 years of medical school (at least in the US) and as different as the two groups see themselves, their training is more similar to each other than to the other two groups.

[2] If you were wondering, I don’t know where Management and Administrative types would fit on this spectrum. I suspect they would be a whole separate category when it comes to problem solving, based on my interactions with them. Unfortunately I don’t have enough experience with the training they go through to develop an informed description and I am similarly uninformed about Sales types.

[3] This is the same scientific method learned in middle school. Your teacher wasn’t wrong about how this stuff would be useful later in life.

[4] The reader may note that the author’s expertise is in the training of engineers and physicians, so where does he get his info about scientists? He is married to a very good one, and she helped him out with this part.

Source :

Related Posts Plugin for WordPress, Blogger...
Be Sociable, Share!

About the Author

has written 1822 posts on this blog.

Copyright © 2017 Medical Technology & Gadgets Blog All rights reserved.
Proudly powered by WordPress. Developed by Deluxe Themes