Your Bioprofile
Modelling user health for user accessibility and utility
Health, and it’s simpler twin “Fitness” are complex topics. In a previous life I, in partnership with nutritionists and general practitioners would help understand their health and fitness and develop a pathway to becoming a “healthier” and “fitter” version of themselves.
Becoming “fitter” is not such a complex task. Fitness can be measured in aerobic capacity (VO2 max), strength in “single rep max” and body fat by way of calipers. To become fitter, one picks a path designed to modify one (or more) of these properties, maximising the amount of change that is possible for the risk of fatigue and injury.
Understanding Health and Fitness
However, the part in which most people struggled was simply understanding their own health and fitness profiles, especially in contrast to those around them who were apparently much fitter and, at least, looked more physically capable. The number of diets is almost staggering and there is an industry predicated on the notion that one's died is incomplete, and needs to be supplemented. The fitness industry has a million ways to solve essentially the same problem with Crossfit, TRX, “functional training”, yoga, pilates, gymnasiums, zumba and all manner of other training styles purporting their own unique benefits. For consumers, there is an abundance of information about health and fitness but few ways to access it without needing to buy in to a given philosophy or movement.
Further, the vast majority of health and fitness impact doesn’t happen within the limited view of time that we spend in gymnasiums, sports centres or thinking about our diet. It is part of the fabric of our lifestyles; our work, family, commuting, hobbies, friends and peers. Our health is impacted by the sum total of these actions, and yet we have little visibility into how they affect us — especially over time.
It is essentially impossible even for me, as a user who both understands a reasonably large pool of both technology and fitness to quickly determine where I sit on the health continuum.
Becoming the masters of our own health data
We are starting to see the emergence of technological solutions that sit quietly in the background, collecting health data:
- FitBit collects heart rate, steps and sleep data.
- Android (Google Fit) collects distance travelled
- Android Wear collects the same heart rate, steps and sleep data.
Each of them provide a better reflection of our activity levels than any insight that could be gained from an hour discussion with ones coach. They provide an objective measurement over an extended period of time and we can look back retrospectively at these measurements when our subjective health improves or starts to wane.
However, there are limitations to the current health implementations. Primarily, they’re tied to a single ecosystem interpretation, and the systems are inherently designed with a view to maximise participation within that ecosystem. FitBit benefits primarily from units sold, and while Google provides a model that is fairly easily accessible for all users it’s API surface is limited.
Centralising our data
As earlier mentioned, there is currently a disconnect between those who have an in depth, nuanced understanding of health (healthcare professionals) and consumers who are navigating the plethora of solutions sold to improve their fitness.
However, that’s not to say that there is not an extremely large set of knowledge about both what constitutes and what improves health. The problem is the disconnect; attempting to cut through this information with some canonical representation of health and fitness. This is a problem that is uniquely suited for a resolution reminiscent of networked computer systems — the development of an API.
An API is the encoding of human paradigms in a way that makes it easy for machines to communicate about. If we are to consider the notion of a “weight” measurement, we can reason that:
- It was taken for some user
- It is some unit of measure (for example,
80kg) - It is taken at some time
- It is taken in the context of some equipment (for example,
OMRON BF511)
This is usually expressed in an excel table or similar, as:
User: Andrew Howden
Type: Weight
Scale: OMRON BF511+-------------+---------------------+---------------------+
| Date | 2018-01-01 08:01:00 | 2018-01-02 09:38:00 |
+-------------+---------------------+---------------------+
| Measurement | 81.31kg | 82.21kg |
+-------------+---------------------+---------------------+
However, it’s also possible to represent this data in such a way that many different pieces of software can reason about it. Consider the following protobuf definition:
syntax = "proto3";package sample;message Date {
// A date expressed as the form RFC3399
// For example, 1996-12-19T16:39:57-08:00
//
// Must include timezone information
string Date = 1;
}message Equipment {
// The name of the entity that created the device
//
// Distinct from brand. For example, given the Pixel 2, the Manufacturer
// would be "Huawei" and not "Google"
string Manufacturer = 2;
// The model of the entity. For example,
// - pixel 2
// - fd283
string Model = 3;
}message User {
// The uuid associated with a given user. For example,
// - 43f94a6e-11a9-11e9-8bcf-7f5a31b3ba35
// - 4ee0ae22-11a9-11e9-9485-236ae6af9e47
string ID = 4;
}message WeightMeasurement {
Date date = 7;
User user = 5;
Equipment equipment = 6;
// The weight in grams
int32 weight = 8;
}
This accurately defines the nature of each measurement in far more detail than can otherwise be captured by humans. Additionally, the above definition in the protobuf (or transpiled JSON) format can be read by almost any software. Given this independent format many different applications can be integrated with the data, each providing their own perspective on it. For example,
- A fitness app might allow recording fitness specific data automatically
- A nutrition app might allow submitting food choices
- Scales might automatically push the data to the service for later analysis
- Coaches might review the data periodically with a view to understand the users health and fitness
- Medical professionals might review the data when attempting to understand chronic disease
APIs in and of themselves do not make for successful data storage pools; they’re fundamentally technical abstractions for a human problem. However, by providing both the APIs and guidance as to what each type means, how it should be understood by implementers, it’s limitations and how to reason about it might provide a standard model with which to consider this data, and allow healthcare specialists to give advice directly to consumers based on this data, or encode their knowledge into software that makes the same recommendations given the data supplied.
An approach that both addresses clarifying the human aspect of health and fitness and provides a model that allows submitting these very human tendencies would be well suited to address this otherwise disparate set of information.
Sharing that data to give us all context
Such a service, if well designed, would see a reasonable adoption and have access to a large pool of consumer healthcare data. The value of the data is multiplicative, and serves to establish norms that put consumer health in context.
For example, given the previous “weight” scenario users might have their expectations set to lose 1kg per week. However, balance of probabilities users who wish to lose weight also have poor cardiovascular capacity and will thus struggle to burn the appropriate amount of energy to lose 1kg a week without significant and potentially unsustainable changes to their diet. However, if users both shared their data and were able to see the data of others, they would be able to explore how other users responded to interventions such as increased physical activity or dietary changes and set reasonable expectations for their own transformation.
Sharing this data opens up clear privacy concerns. To mitigate this, data would need to be shared only once such a sample of data was available that users were guaranteed anonymity for their own data.
Sharing the data with others
Once users had this pool of health and fitness data in their control, they may choose to share this data with other professionals who are seeking more insight into how to provide the best advice to that user, or services that were able to provide value based on this data.
An initial implementation of this would allow medical professionals such as doctors, nurses, nutritionists and coaches access to this data in a view that benefited them while undertaking their analysis of a users health. These practitioners could then propose interventions that should help users improve their health profile, and be able to investigate further should that intervention not work as anticipated.
However, the possibilities may extend laterally. Given a users body measurements, it would be possible to tailor clothes to them. Or, given their nutritional profile it might be possible to tailor a diet to a specific outcome.
In Conclusion
There is currently a market gap for a service that provides a good model of a users health and fitness that is both accessible to users and third parties in equal measure, with users permission. Such a model would need to remain independent from all third party implementations, and be designed only to express health and fitness data as accurately as possible in standard form. It would additionally have to place the user at the centre, giving that user ultimate control over that data and allowing the user to delegate control over the data to third parties.
This is the plan with “moar fit”: https://moar.fit. However, I’m currently not sure how much time to dedicate to this — I think it’s a valuable service, but this post is a “market fit” test. It would involve a monumental amount of work and coordination, and I’m not even sure whether it’d be successful.
Keen to hear what ya’ll think. ❤
