2023-07-17: Health trackers, a non-trivial problem

You might know that I'm writing a health tracker for AsteroidOS smartwatches called [asteroid-health](https://git.dodorad.io/dodoradio/asteroid-health). It actually comes as two packages, the second of which is [sensorlogd](https://git.dodorad.io/dodoradio/asteroid-sensorlogd), which does the actual logging and hopefully will be appropriate for more than just health tracking. I'm not sure there's been anything like this before for mobile linux, and while there have been some health apps for android, I'm still having to solve quite a few problems from scratch. *** The first question is 'what do we actually expect a health app to do?' It's fairly easy to show steps and heartrate, but it's not always easy to understand that raw data. A simple number would be easy to compare, and lets the user know if they've done a good job or if they need to do some more work. Steps are a fairly easy metric to gamify. We set a goal, if the user hits the goal we congratulate them. Step goals seem fairly common across health apps, because it's an easy number to compare with friends and walking is an accessible form of exercise for people who are otherwise not sporty. However, the step counter sensor doesn't know about static activity and misbehaves with bicycles and rhythmic resistance exercises, so it can't be our only data point. Otherwise, it would be desirable to give the user an overall health score of some sort, with a daily goal of getting that score above a certain level. Calories (really, kilocalories in most cases) serve as a much better marker of activity, but they're hard to measure. For spacial sport activities, such as running, jogging or cycling, the maths is well documented. There are a few equations involving parameters such as speed, distance, time, weight and height, which can give acceptably accurate estimates. And, even if the resulting calories measurement is not particularly accurate, it is much easier to analyse data such as pace, time and heartrate in the context of intensive sport activities. But GPS and continuous sensor monitoring are power hungry, and will likely drain a smartwatch battery in under 3 hours, and while this is appropriate for heavy sporting activity where stats are highest priority, it is totally unreasonable for day-to-day health tracking. Idle activity calorie calculations seem to be an art more than a science. There's a lot of rules-of-thumb about what is healthy and what isn't, how much of one exercise is equivalent to another exercise, but it's not very clear from a data analysis point of view. [This paper](https://sci-hub.hkvisa.net/10.1123/jmpb.2018-0003) perplexingly suggests that heartrate doesn't make it any easier to calculate calorie expenditure than other data points. I guess that Fitbit, Apple, Samsung and others are using big data analysis to correlate all those data points together, a privilege afforded by their massive archives of user data. They probably also have access to labs where they can get much closer to the original calorie expenditure reference, from which they can then draw their data. Since I don't have access to that equipment, my closest reference comes from the implementations of their research, i.e. the fitbits and apple watches which are making assumptions based on other data points, and which are known to be off by up to 30% (see the paper above). By building my solution with the apple watch or fitbit as reference, instead of getting closer to the truth, I will just get closer to whatever compromised solution they picked. The Big Data analysis is also something I'd like to try, but it's not practical, again, because I'm not a big company. I'm also not sure I want to 'throw AI at the problem' because that will make my code as much of a black box as Apple's. > ## Sidenote: A healthy approach to measuring health > It's also worth discussing the drawbacks of calorie calculations. [A raw calorie count isn't necessarily motivating for people who want to lose weight](https://www.sciencedirect.com/science/article/pii/S2214782916300392). We don't want the user to become demotivated on their weight loss journey. Additionally, calorie counting is also [linked with eating disorders](https://www.sciencedirect.com/science/article/abs/pii/S1471015316303646). A health app should be sensitively designed so that it doesn't affect the user's mental health. > It's tempting to write some algorithm that rates a user's current health absolutely. For this, one might consider weight, heart rate (both resting and the proportion of time spent in various zones), food and caffeine intake etc. against data such as age, height, sex. While there is some value in this sort of analysis, I think it can go wrong quickly. Firstly, I'm not a health professional, and my code is even less professional, and I don't want to make bad mistakes about the user which might cause them to take on a radical new health regime, or worse, trigger stress, insecurity or an eating disorder. Secondly, I think that the app should be an assistive tool and not a prescriber. This means that the app should be entirely under the user's control and the goals should be set by the user. Thirdly, people are different, have different goals, different bodies and will want to use the app to achieve different things. Hence I'm definitely not putting any BMIs or pacer tests in my app. So I'm not sure there's any value in exposing a raw calorie count to the user. The value would be inaccurate anyway. As the app aims for higher accuracy, the algorithm used to calculate calories would get more complex, and hence it would be harder for the user to spot errors in the apps calculations, which would be misleading. I imagine that calorie counting is added to mainstream smartwatches as a marketing maneuver, because I'm not sure how else to justify the horrible accuracy. I'm not trying to sell the app, and I'm focusing on making accurate data as easy to read as possible, so calorie counting still doesn't have a certain place in my plans. It would sitll be possible to calculate some number that roughly correlates with activity and daily physical load, and I think this is a good basis for our 'health score' - a sort-of calorie measurement that doesn't sound as confident and authoritative as an actual calorie measurement. Of course this is still going to be limited, as it only covers what we can get from steps, heartrate and altimeter. Most health apps boil down to a complex frontend for a database. Current linux apps (such as gnome health or gnu health) make no effort to hide this, as all their data is directly input by the user, while smartphone apps make every effort to hide their database nature. The former is limited because most linux devices have no health sensors attached, so logging is impossible. In the latter context the experience relies on making data accessible only through the app, and by processing all the data with various algorithms - this is useful, as it makes the data easier to digest and makes the app seem less imposing, but it doesn't end up being super productive. I hope that asteroid-health will strike the balance between these two philosophies, providing both the usefulness of a classic database with the conveniences of simple data access and analysis, but I also want to keep it out of algorithm hell. Usage of asteroid-health will still be more imposing than most mobile health apps, as it won't do too much on its own, and I think that wil make it a more useful tool. Maybe in future there will be room for more complex data analysis, or for basic healthy eating recommendations, but it's worth making sure that's done correctly. In the mean time, look forward to more powerful graph views, air pressure tracking and weight logging!