Problem solving is a key part of what we do as doctors: that’s what the diagnostic process is. As seniors it is our responsibility to help teach this skill and train our junior colleagues in it but do we actually understand how our brains solve problems and how that might apply to our clinical practice?
There are a number of models out there that consider how we solve problems and one that is currently very popular is Computational Thinking. Although this model has been around since the 1950s, it has gained in popularity recently because it is a useful strategy for translating real world problems into a format that computers can help solve. For this reason it is a strategy that is now often taught in schools and as such may be how our younger colleagues are actively approaching clinical cases. It is important to understand that, despite its name, Computational Thinking is NOT about learning to think like a computer, it is instead a very human way of solving complex problems. When I describe the processes involved, I am sure you will recognise them and see that it is quite possible that many of us adopt this strategy in our clinical work on a daily basis.
The process of Computational Thinking is often broken down in to five parts:
The process of taking a complex problem and breaking it down in to smaller, more manageable pieces.
2) Pattern Recognition
Spotting issues within the bigger problem which have been encountered before and for which solutions may already have been found.
Deciding which information to focus on as important and which can be filtered out as irrelevant.
Creating a stepwise process to work through the problem and reach a solution.
A review process where outcomes are evaluated against expectations, allowing successes to be recognised, errors identified and corrected and the processes refined accordingly.
Presented like this I am hoping you can already recognise a process you use in your own general thinking and also how it might apply to our clinical work. Let us consider a fairly familiar presentation to a UK Emergency Department.
Mrs Jones is 87 years old and has presented with an obviously broken right wrist sustained in a fall whilst putting the bins out this afternoon. She isn’t sure how the fall happened and admits that she may have blacked out, something that has happened twice before in the last month, once at a birthday party and once at home. She lives with her 88 year old husband, an ex-policeman, who is blind and so she is his main carer. The nurse who triaged her says she seemed a little confused on arrival and when she phoned Mrs Jones’ daughter, who lives in Dublin, she explained that she thinks her mother may be developing dementia and would like a formal assessment of this done before she is discharged home.
This is a complex clinical problem but those of us with significant experience would probably break it down in to smaller, more manageable parts: the wrist fracture; the fall/collapse; the possible dementia; the social situation; the daughter’s demands. Whilst these parts are not mutually exclusive, identifying them as individual components helps us not miss some issues and also allows us to consider and process each problem, in part, on its own terms. With these parts identified we apply some pattern recognition: wrist fracture in the elderly; collapse ?cause; ?confusion in the elderly; carer issues; concerned/demanding relatives. We have dealt with all of these in the past and have mental plans ready, allowing us to prioritise and focus on the core problems whilst we filter out the currently superfluous information at this stage. We put plans in to action for each of the pieces of this particular puzzle: x-rays and possible manipulation of the wrist; ECG and bloods for the collapse; contacting GP practice about the confusion and possible blackouts; looking at the current social care package and considering discharge options; understanding the relationship with the daughter or other relatives.As the case progresses we constantly review the outcomes of each step, adjusting our expectations, altering the plans as abnormalities are found or hurdles are unexpectedly cleared and reviewing the information that we thought was irrelevant to see if that has changed.Above all we regularly reconstruct the pieces of the puzzle into the whole to see if the ‘big problem’ is being solved as we had hoped.
For many of us the above happens with ease because of years of practice* but what about those who are new to this type of situation? Understanding the process of Computational Thinking can help us give less experienced colleagues a structure in which to solve problems whilst also helping us to understand where and why they may be stuck when they approach us for assistance.
When a junior comes to you for help with a case, perhaps like the one above, they could be struggling in a number of ways.Without skilled decomposition they may become overwhelmed by the details of a case or alternatively fail to tease out all the relevant issues. An inexperienced doctor will have no patterns to refer to and find every problem difficult to solve whilst a clinician with experience may reach for their patterns too soon, making assumptions and jumping to conclusions. With a failure of abstraction some will struggle to find a focus to their thinking, worrying about every part of the case whilst others will filter out anything but the most obvious cues and fail to understand the subtlety of a case. Limited algorithmic thinking leads to the creation of poor plans, will result in failure of a case to progress in an appropriate direction and at an appropriate pace, either too slowly or too quickly. Finally, if a junior cannot debug their case their plans will be inflexible and they will tend to get stuck when results are unexpected, possibly ignoring them or explaining them away. They will also struggle to learn and develop as they are not good at evaluating success or failure in their clinical work.
Knowing which part of the problem solving process is at fault allows us to concentrate training in that area and to make sure both we and our trainee get the most out of our interaction. There is limited value discussing the review process of a sepsis case (debugging) if the real problem was an inability to formulate good differential diagnoses in the first place (abstraction). Spending time looking over the paediatric DKA guidelines and how to use them (algorithm) won’t really help someone who didn’t start the correct treatment because they thought it was just another teenager who was hyperventilating (pattern recognition). Matching advice and education to the underlying issue is more likely to result in improvement for the trainee and to be more satisfying for us as trainers.
Below is a table which describes what these Computational Thinking processes might look like when they are going well and what they might look like when they are not, along with some suggested actions to help improve that area of problem solving.
Next time a junior comes to you asking for help with a case, consider if this is a problem solving issue and whether the process of Computational Thinking may have something to offer you both.
* It is interesting to look at this pattern of problem solving and draw parallels with the OODA loops model John Boyd proposed for the rapid thought processes of expert problem solvers. Observation takes in the available, usually complex, information and then the Orientation phase uses decomposition, pattern recognition and abstraction to establish and prioritise the problem(s) faced. Further abstraction occurs during the Decision phase and leads to an algorithmic plan being formulated which is then put in to action during the Act stage. Between each phase debugging occurs against expectations and creates the feedback loops that drive the whole process forward.