Bridging Design Gaps – Comparing Engineering and Physician Approaches to Problem-Solving: THINK & CHOOSE

Welcome back!  Today, we are going to continue our ongoing discussion here at The Lonely Surgeon that has been going on for a few installments now.  It’s a big topic, so it takes awhile!  To recap, we have been examining how engineers and physicians approach problem-solving to see why disconnects happen so often in the biomedical innovation world.  Previously, we defined our generic problem-solving model that applies to both disciplines.  We also took a look at the first step in this process IDENTIFY.  Today, we’re going to continue down this road.

For your reference, please allow me to just refresh you on our model:

Generic Problem-Solving Model
Comparing Steps 1 & 2 from the Generic Problem-Solving Model

We spent quite a bit of time looking at Step #1 IDENTIFY last time.  Without rehashing all of that, I would like to bring one summary element from that article into our discussion today:

Engineers and Physicians may identify different problems based on their knowledge and experience

So how about our second step?  THINK is actually pretty straightforward, but the results can look vastly different.  In both cases, Engineers and Physicians can obtain and analyze data.  Each can also look at this data and generate possible solutions to our problem.  Unfortunately, this is where our similarities sometimes end.  Often, we get boxed in by our personal expertise when we are thinking about how to solve a problem.  There’s an old saying: “If all you have is a hammer, everything looks like a nail.”  These words were never more true than during the THINK process.  With much respect and deference to my interventional cardiology colleagues, a good example of this is the ongoing debate between stenters and surgeons—if you aren’t trained to perform an open surgery on a patient, you may start to get creative with your wires/balloons/stents because that’s what you have in front of you.  Nothing wrong with that approach… sometimes.  In fact, one could argue that without this kind of ingenuity, the entire field of endovascular aortic repair wouldn’t exist today!  And without our engineering friends and their expertise in manufacturing and materials science, no doctor would have been able to actually build an aortic stent graft delivery system.  In each case, the expert in the field helped to inspire the others and brought the knowledge to the table that allowed this wildly successful collaboration to save countless lives all over the world since 1987.  But is it always the best option?  Or is the old-fashioned approach sometimes superior to new technology?  You may be able to pry an old screw out of a wooden board with a pair of pliers and a hammer, but wouldn’t it be better if you just had a screwdriver in the first place?

So what about that last line from our table?  You know, the two little statements highlighted in blue at the bottoms of those two lists?  Well, this is where we really diverge…

Engineers frequently have access to all kinds of testing resources.  Some are built in a back lab somewhere.  Some are designed wholly in a computer simulation environment.  The technology used can be cutting-edge new or anciently old.  Sometimes, this testing needs to be done in the field.  They may have limitations based on what equipment they have available or what the budget restrictions might be.  Time is also a common limiting factor.  Hey, it’s tough being an engineer!  When an engineer comes up with her list of possible solutions to her problem, she has to take all of these things into account. 

Physicians, not surprisingly, have the same problem!  But with one major difference: Physicians treat people.  Patients.  Unpredictable, non-compliant, squishy little humans who are often burdened with mysterious limits called “service not covered” or “not on formulary.”  I don’t know about you, but even with multiple postgraduate degrees in a variety of data-driven disciplines, I still struggle to figure out my insurance coverage every year.  These decidedly human factors can play a huge role in the success of your potential solution.  You can write a computer code line to tell the system to stop doing something.  Talking to your patient about smoking cessation often isn’t as effective.  When I transitioned from electrical engineering into the biomedical world, one of my professors gave me some advice.  He said, “You may be used to having a system efficiency of +95%.  Get over it.  In biology, you’ll be lucky to get anything over 60%.”  In retrospect, I would drop that number even lower for some aspects of human medicine.  I’m still searching for the model that will accurately predict whether or not my patient will show up on time for his clinic appointment… or if he shows up at all.

An engineer in the field has to deal with external factors that may affect the possible solutions on her list.  Heat/cold, dirt, vibrations, friction, material defects, supply chain delays… All kinds of unpredictable stuff.  Physicians have to deal with the sticky, hairy fragility of the human body and all of the crazy predicaments it finds throughout life.  Plus, we have the human brain making all sorts of choices all day long.  I would hope that a computer wouldn’t be tempted to eat Twinkies and binge on Netflix all day long instead of performing the instructions it has been given.  People, on the other hand… Ehh, you all know how it goes when it comes to Twinkies… 

The advantage that physicians have in this biomedical space is that the physician probably knows about the Twinkies-and-Netflix tendencies of patients.  In fact, the physician may be counting on it when she develops her list of potential solutions for her patient’s problem.  That might not score as highly on the engineer’s radar, unless that engineer has had prior experience with a computer and a Twinkie.  So as our Engineer and our Physician continue to develop their respective lists of potential solutions to the original problem, they start to make some choices.

CHOOSE

I would like to expand our previous table to include Step #3 at this point:

Step 3 of the Generic Problem-Solving Model

At this point, each scientific expert must select an option from the previously-generated list of possible solutions to test.  There are several factors that may affect this selection process:

  • Ease of implementation
  • Access to resources
  • Time available
  • Cost
  • Likelihood of anticipated success

Does this list apply to Engineers?  Yes.  Does it also apply to Physicians?  Yes.  Just like my initial foray into this discussion, the models are essentially identical when it comes to CHOOSE.  The better question, however, is the following:  Would the Physician and the Engineer pick the same solution if given the same list of options?

Hmm…

Can we sum this idea up into a single statement?  Let’s give it a shot:

Engineers and Physicians may generate and select different potential solutions for testing based on their knowledge, experience and available resources

Not dissimilar from our Step 1 summary statement, eh?  The kicker here is that last phrase: available resources.  As our two scientists come may come from very different worlds, their lists may look vastly different just because of their respective environments.  But what if they knew about each other’s resources?  Would their lists begin to look more similar?

Again, hmm…

THE HOMEWORK

So the homework for this week, should you choose to accept, would be to find your friendly colleague from another discipline again.  Offer to buy her coffee for having pestered her so much.  Then ask her to jot down a few options that she would consider when asked to solve a common problem.  You do the same thing.  Don’t prioritize any of these options—Instead, just trade lists.  Each of you should then pick the solution you think would be best to address this problem from the list you are given.  Then tell each other your answers.  Are they what you would have expected?  Why or why not? 

The plot thickens…

For our next episode, we’ll have a little fun looking at Step #4: TEST.  Ooh, boy!  Fasten your seatbelts!

Until then…

TLS

Photo Credit: Arek Socha from Pixabay