A common failing I've noticed in complicated multi-symptom diagnoses like this disease is that doctors tend to treat each symptom individually instead of trying to connect the dots of all the symptoms. As a programmer used to debugging complicated systems it makes no sense, my first inclination when multiple things popup at the same time is to look for the underlying root cause.
I think this sort of thinking involves a false equivalence between computer programs and the human body.
Going out on a limb I'd say that debugging is a skill that's learned in practice, not taught, so if it was as easy to "debug" the human body as it is to debug a computer program, why would computer programmers be better at debugging in their domain then doctors are in theirs? Surely doctors would have varying degrees of skill in this regard, but so do programmers, and it's likely that a) "good" doctors would count this "debugging" as one of their most important skills and b) that Robin Williams had really good doctors.
These factors seem to make diagnostic medicine quite challenging:
* It's often impossible to gather the information you need to make a certain diagnosis without an endless series of tests that may be prohibitively expensive or dangerous to the patient's health themselves.
* Feedback to attempts to "probe" the problem e.g. trying a course of a certain medication may be very difficult to interpret because of delayed reaction, individually unique responses, and/or other external factors that make it difficult to attribute some observed effect to cause X.
* The patient is not getting any younger this whole time, and may become impatient with the process and accept an imperfect solution or simply not have enough time due to the progress of their illness for all avenues to be explored.
* Patients may deliberately hide some of their symptoms, e.g. the article's author's theory that her husband was keeping hallucinations secret.
One reason why we might be better at debugging is doctors are penalized for "fuck it, what happens if I do..." and we are not.
We get to mess with large permutations of different causes and effects, that we stimulate, in a short time while that would be unethical for medical professionals.
> One reason why we might be better at debugging is doctors are penalized for "fuck it, what happens if I do..." and we are not
I get anxious every time I have to debug live systems. Developers are lucky because we can reproduce and test fixes on non-live systems. As a bonus, we can step through the code at critical junctures and can examine the complete state of the system
When you have a large, distributed system with many moving parts, debugging no longer applies. To top that off, you in no way have a complete "view" of the state of the system and you have to piece together clues from varying parts. Taking into account the user "story" of what happened, which is usually vague.
I always liken it to being a detective trying to piece together a crime scene from incomplete clues. But now that I think about it, it's also quite a lot like trying to diagnose an illness from symptoms.
I'd debugged live systems that where for side projects. One such example was a game server who I wrote a few thousand lines of code for. All with no test suite, all with no other eyes inspecting it, absolutely no documentation, and all with a usually incomplete git history.
I had about 2-4 systems talking to each other for this project (that's counting the system that I wrote that works as a plugin/module loader and all of it's plugins as 1 system).
It's a relic from my past that I'm glad I left behind. Editing plugins live, writing everything in usually the one or two days of free time I had between school engagements, and a few other tricky things that happened, this was probably one of the most funny projects I worked on.
By the end of it, I had two config file formats for pretty much everything, I opted out of using the right tool for the job most cases, and I kept having to upgrade hardware which was a pain in the ass since I didn't have any setup instructions since I made the damned thing.
It was quite a bit of a mess and I can definetly agree, debugging live systems, debugging distributed systems, and debugging unverified/untested/undocumented systems is crap too.
I'm pretty sure that being a doctor is the same as this except thousands of times worse. The amount of times I've messed up when working on my spaghetti plate was more then I can count and I'm pretty sure the human body is more slopily put together then my leaning tower of crap.
Systems programmed by humans typically have coding standards. The human body on the other hand has been haphazardly developed over billions of years by the principle quick hack on top of quick hack on top of quick hack.
It's a complete mess of spaghetti code where anything that happens is the result of dozens of sub-systems trying to invoke or override each other.
I like to keep that in mind when I consider what kind of solutions machine-learning will bring us, what kinda processes will be going on under the hood.
> my first inclination when multiple things popup at the same time is to look for the underlying root cause.
The problem is that programmers can make a hypothesis and then test while doctors can't.
Doctor's are effectively engaging in "shotgun debugging" because they don't have good "this cause to this effect" for a lot of systems. The drugs they have to effectively "unit test" don't have narrow effects, so those add extra uncertainty.
They're getting better. And I wish the "deep learning" people would target this much harder--it's almost an ideal candidate (we have these symptoms--we ran these tests--give us a probability list of the top 5 things we should be ruling out next). However, getting the data seems to be the problem.
You treat the symptoms because the patient is suffering, not to solve the problem.
If you have a live system bringing in millions of dollars everyday but it hangs every once in a while, do you reboot it, or attach a debugger to it while it's hung?
I think the old "if all you have is a hammer.." applies here.
My father is now being treated for dementia, unknown cause, but they suspect Alzheimer's. Several months ago he was hospitalised after a psychotic break. When he was being admitted, I told the psychiatrist about my late grandfather's dementia but it went unnoticed. After several months of antipsychotics (which did remove the delusions) and antidepressants his condition did not improve. In the end she finally ordered brain scans and performed a full barrage of blood tests and a neurological assessment to discover there is brain sclerosis.
First of all, sorry about your father. My comment that follows is in no way trying to diminish what you have been through. Please do not take it that way.
What your describing sounds a lot like team debugging and trouble shooting! Trial and error of a failed hypothesis, further testing when someone looks at the data with fresh eyes. Finally a solution, or in your case, clarity.
Unfortunately, it was the worst kind of debugging, throw drugs at the problem and see what sticks. If it doesn't work change the dosage, then some more drugs to counteract the side effects, then clean up and start over. It feels so unscientific and medieval.
You see the same thing in nutrition and exercise. A lot of people want to boil down every issue to a single factor. Either fat is the only problem or sugar or carbs or whatever. The body is a complex system and a lot of factors have to be in balance. But I guess that's hard to communicate and work with.
What you call a complicated system is trivially easy compared to the complexity of the human body. The truth of the matter is that humans alone are simply not good at this. There is way too much information that needs to be considered both about the individual patient as well as medical knowledge of diseases.
What is necessary is to force the medical community to build up better tools for medical diagnostics and the storage and exchange of patient health information.
Clinical systems interoperability has improved a lot in the past few years. But decision support and automated diagnostic tools (like IBM Watson) are still constrained by lack of complete and accurate patient symptom data. It takes a lot of time and expertise to correctly observe symptoms and enter them in a way that computers can understand. I don't think that automated diagnostics will be widely used until computer vision, pattern recognition, and natural language processing advance far beyond the current state of the art.
Lack of systemic thinking across a great many areas is unfortunately overly common. Including in software and technology, but hardly limited to that.
Answering the criticism raised in several responses, it's not that a deep and systemic understanding is specific to software, and inapplicable elsewhere. Yes, the fact of a human-constructed system may make the intention of a system clearer, and its detection easier, but the entirety of existance, at least as our brains are fundamentally equipped to make sense of it, is a system. Primary phenomena are rooted in underlying systems, prerequisites, causes, and interactions. "Five whys", or any other set of inductive explorations, is not a privilege of software systems and workers alone.
The asystematic approach is one that is, paradoxically, a result of increasing complexity of knowledge itself. Rather than individuals spanning multiple disciplines or even subdisciplines or specialties, they're are trailed off into individual leaf-nodes of research, skill, and application, and efforts to break out of this pigeon hole are obstructed at virtually all levels of the system.
Pay and reward are largely commensurate with specialisation. Reputation is contingent on specialisation. Procedure compensation is contingent on specialisation. Access to diagnostic equipment is contingent on specialisation.
And so forth.
Each individual member associated with treatment has their own very small aspect as their particular area of concern.
In software, it's like the person who resolves a bug in medical pricing codes by simply applying the value that was expected in that specific instance for a price, rather than, say, fixing an algorithm or lookup table such that the right answer appears regardless of specific circumstances (I'm paraphrasing from an actual bug/fix story seen recently). From the point of view of a naive management system, that worker has a very high bug resolution rate -- but they're treating the symptom only of an underlying software deficiency.
In a similar vein: you can "fix" a water spot on a wall by repainting the wall.
Or you could replace the plaster that's been waterlogged.
Or you could seal the exterior wall leak that's allowing water in.
Or you could shore up the foundation that's settled, allowing the wall to leak.
Or you could address the underlying geology -- a sinkhole, ground subsidence, a fault line -- that's causing the foundation to move.
Paint is cheaper than plaster is cheaper than siding is cheaper than concrete is cheaper than earth-moving equipment. And there may be an appropriate level of fix. But walking through the problem to its fundamental source(s) provides a full understanding of the problem.
