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.
Video of seminar: Opportunities and Challenges in Surgical Robotics…