Bridging Design Gaps – Identifying Problems and Possible Solutions

So in the past few posts, we’ve laid a little groundwork for our next discussion.  Going back to our original question, why do engineers and physicians struggle to collaborate sometimes when developing medical technology?  There are many amazing exceptions to this generalization, but I’m sure we can all think of instances where design engineers and clinical experts look at each other as if an alien ship just landed in front of them and a little green person walked out.  In my last article, I tried to go back to some basics by defining a generic framework for problem-solving that both groups seem to share:

Today, I would like to dive into the first two steps of this process a little more…

IDENTIFY

We’ve all been there—stuck someplace we never wanted to be, no idea how we got there… and no idea how to get back on track.  How do we solve this problem?  Subconsciously, our brains like to start with the known elements.  They are often much easier to grasp, especially when we are confused or stressed by a problem.  So what do we know?  We can look at our physical surroundings.  We can look at recent events.  We can assess our current resources.  At the end of it all, however, we need to pull these puzzle pieces together and define our problem.  If we can’t do that, there’s a good chance that we will continue to stumble around lost in that desert.  By identifying our problem, we can start to set parameters for some possible solutions. 

Sound fair?  I hope so.  Back in physics class, we had to do story problems over… and over… again.  The professors would say that drawing a free body diagram [FBD] would often make the solution more clear.  The Notorious FBD was usually a little sketch on the side of my notebook page that looked something like this:

By drawing a picture, it became much easier to define forces acting on a mass, their vectors and subsequently the equations that were needed to balance the whole thing out.  The FBD made the whole hot mess much easier to understand.  The hardest part of the problem became making the initial sketch.  Once you did that correctly, the rest was just plugging and chugging.

Medicine can be a bit murkier… You see that a patient has consistently elevated blood pressures.  You prescribe a medication.  You bring him back in a month to recheck his blood pressure.  If it’s improved, you’ve fixed the problem.  If not, well… Was it the wrong medication?  Did the patient take it correctly?  It’s a little harder to draw a free body diagram in this case, but not impossible…  It will just look a little different.  Fortunately, successful physicians are usually savvy enough to ask the right questions to figure out where the problem truly lies—sort of a physical/psychosocial FBD, if you will.  Once this has happened, the problem-solving model can kick back in.

THINK

Once your engineer/physician has identified her problem, she can start to think of different possible solutions.  These can be wide-ranging.  Sometimes they may involve existing technology, but sometimes a little outside-of-the-box thinking needs to happen.  Some solutions may not involve physical technology, but they may instead focus on the environment of the problem.  Controls and process workflows are often key factors that can wreak havoc in almost any case imaginable—can’t forget about those!  This is the part where you can let your brain run a little wild.  Creativity, experience and attention to detail all play a major role in the breadth and quality of the possible solutions generated.  This may mean that some people are a little better at this than others, but idea generation is a skill that usually takes a little practice.  Once you get the hang of it, the ideas will flow forth like Niagara Falls.

COMPARE & CONTRAST TIME

So engineers and physicians can both do these two steps, right?  Easy enough.  But there are a few key differences:

Let’s think about this first step IDENTIFY for just a moment:

• Engineers and Physicians are both able to identify problems
• Engineers and Physicians may each identify different problems at different times

Ah!  So an engineer may notice that a skin sensor biowidget isn’t working because the power supply is corrupt.  The physician may realize that the same biowidget isn’t working because it isn’t sticking to the patient’s skin when moisture develops [because let’s face it—we’re a damp species sometimes.]  The physician is certainly capable of realizing that the power supply isn’t working, but would it be the first thing she would notice?  Maybe.  Maybe not.  And would that engineer realize that a patient is sweating while laying in a hospital bed and that the biowidget stickers keep coming loose?  Probably… but maybe not at first.

So let’s make a generalized statement about this:

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

Is one more valuable than the other in our biowidget example?  Of course not.  Both problems will make our biowidget no more valuable than a paperweight.  Does it matter which one is discovered first?  Perhaps, but not necessarily.

THE HOMEWORK

For the sake of your patience and attention span, I will save our discussion about Step 2 for next time.  In the meantime, I invite you to do a little exercise this week: Find a colleague from another discipline and ask her about a problem common to you both and what she feels may be the underlying reason for this.  Don’t offer any input until you’ve listened to everything she has to say—and you might avoid controversial topics, just as a little friendly advice in advance!  Consider how her answers may be similar or different to your own.  Would her imaginary FBD have looked at all like yours in this situation, or did she come up with something different altogether?  Most importantly, can you see how she arrived at her answer?

If so, you’re on the right path!

We will dive more deeply into Step #2 THINK in our next installment.

Until then…

— TLS

#thelonelysurgeon #surgery #medicine #physician #business #innovation #design #identify #choose #solutions #development #scientificmethod #collaboration #teamwork #science #engineering #goblue

Photo Credit: Free-Photos from Pixabay