Diabetes, Article - The real problem to solve
Disclaimer. As with all articles, and especially this one, I must emphasize that this represents the perspective of a software developer. I am not a physician. I'm simply trying to synthesize what I've observed working, or not, across different countries, healthcare structures, and socioeconomic contexts. Nothing written here, or elsewhere on this site, should be considered medical advice.In the diabetes management software space there's a tendency to apply whatever technological trend is most popular at the moment (machine learning, AI, internet of things …) to see if it can improve patients' lives. Unfortunately, this approach rarely works effectively.
For individuals with diabetes, there are many problems to be solved, and every solution to each one of them influences the other problems as well. A lot of new methods can solve very specific tasks, but when researched and applied in a vacuum, they rarely get any net benefit.
Healthcare related conditions differ from patient to patient, change over time, and require a systematic approach to tackle them effectively. Fortunately I think we can still do something about it.
How We Arrived Here
This isolation between research and application of software solutions stems from multiple causes.
Academic research is often driven toward the use of methodologies that will ensure more publications. For example, blood glucose prediction using neural networks is arguably one of the least useful applications, yet it receives the most research attention because there's demand for "cutting-edge" work in the literature. This is understandable behavior and I’m not criticizing researchers, it is a very competitive field, but it's just a fact that sometimes the incentive structures are not ideal to solve some kind of research questions.
Industry sometimes pursues applications that sound promising in theory and work with small research groups, but prove ineffective when generalized to entire populations. Sometimes business’ operations are more aligned with the interests of VC funds or investors rather than with the actual needs of the patients and their caregivers. Again, I’m not criticizing anyone in particular. Doing business is really hard, and doing business in healthcare is ten times harder.
How Things Can Go Right
So if incentive structures make it almost impossible to tackle a lot of problems at the same time, we should identify just one thing, one task to focus on. Or at least a starting point that would make solving other problems easier. In my experience, we should strive to improve the doctor-patient relationship. The most consistent way to achieve this is by providing physicians with insights that allow them to apply their expertise more effectively to specific cases, enhancing, not replacing, their discretionary judgment.
Concretely, the approach I've found most effective is providing physicians with patterns identified in patient data that might be worth investigating during consultations. The key is that while these patterns are classified with some measure of importance (because otherwise we wouldn't add value by suggesting which patterns might be most influential), they are not medical recommendations. They are not prescriptions for what patients should do, they are neutral, non-judgmental indicators of aspects of a patient's life that might be worth exploring during the limited time available in consultations.
Ranking and Prioritization
Now that we've established what constitutes a good problem to solve and a general methodology for addressing them, let's explore some practical implications.
With regards to ranking, the specific methodology isn't as important as understanding the practical implications of results. What matters is the ability to order and assign importance to discovered patterns, enabling quantitative guidance for physicians toward targeted patient investigations. For example, statistical methods are not much more valuable, for the end users, than simpler data mining methods. The important thing is that the method chosen is able to determine which of all possible and plausible patterns are present at any given moment in the patient's life.
Another delicate aspect is what's called jittering in other engineering fields. In diabetes management, we face not only measurement variability from errors and intrinsic physiological model variance, but the physiological model itself changes over time. It's analogous to CGM measurements that have both individual measurement errors and temporal lag errors that are not constant, for example measurements aren't always 20 minutes delayed, the delay itself is variable.
How Things Can Go Wrong
Why do many well-intentioned efforts often lack significant practical impact? I can only speak from personal experience here, so this is essentially a catalog of all the mistakes that cost me years before finding an effectively productive development direction, but I think I'm not far from describing the actual situation of a lot of professionals.
If you're a technician, whether a physician, developer, etc., the primary bias is using available tools to solve problems. Additionally, how you use these tools is strongly influenced by your operating environment. In my case, I focused extensively on refining neural network usage for blood glucose prediction, taking time to realize this wasn't the right path. This happened partly because intense focus on details can obscure the bigger picture, and partly because we unconsciously resist admitting we haven't used our time wisely.
Even when moving in the right direction, for example working on pattern ranking solutions, there are many unexpected consequences that you might experience. For instance, in data-based solutions, requesting additional data logging from patients might actually cause a decrease in therapy adherence in different areas.
There are also resources that can help, if we can set aside our ego at least somewhat. There are papers explaining why some diabetes patient apps fail, and how even discovering a method for non-invasive glucose detection would likely be killed at birth by patent battles.
Thank you
As always, thank you for your time.
If you want to send me something, XY at gmail.com where X = tommaso and Y = bassignana, no dots between X and Y. I'm always interested in hearing any of your comments and suggestions. I respond to every email ;)