openhumans / quantified-flu

Can wearables warn us when we're getting sick? A community citsci project – open source & open data!

Quantified Flu

The project idea

We are trying to collect some data to answer the following question: Can the various physiological parameters tracked by wearables help to predict when we’re getting sick? This is not only related to #covid19, but also the flu and colds in general.

This question came up in the Quantified Self forum, whether resting heart rate could be used as an early indicator for #covid19 infection. Some preliminary analysis for regular colds & flu-like symptoms showed that it's complicated, as resting heart rate can be fickle for lots of reasons. Body temperature data as measured by the Oura ring seems to be a better indicator, as highlighted by a #covid19 patient here.

To get a better understanding of whether our wearables can help predict cold/flu/etc onsets we are planning to do a retrospective study using wearable data that's annotated with metadata about disease onset times.

The current state

This web application is build on the API of Open Humans, which can already import wearable data streams from Fitbit, Oura, Withings and Google Fit. Earlier, Bastian made some preliminary Jupyter Notebooks for data from Fitbit & Oura, but to broaden the scope and scale up collection efforts from n=1 to n-of-many we need a website. This repo is for building that website.

In the current state it can take in wearable data from Fitbit & Oura and visualize it for a user-given sickness-date.

Contributing

There's still plenty to do before this can launch. Check out our Contribution guidelines & how-to and maybe join us in our Slack. You can join the Open Humans slack by creating an account here and join the #quantifiedflu channel.

How to run locally

We have a Makefile with common commands.

• Do make pip once to install dependencies (using pipenv). Repeat every time the dependencies change.

• Create a copy of env.example like so:

  cp env.example .env

  and populate .env with the correct values for OPENHUMANS and data source credentials.

• Every time you want to run locally, do:

  • make deps

  • optionally make makemigrationslocal (if you've changed the models) and add new migration files to Git.

  • optionally make migratelocal (if setting up locally for the first time, or if you've changed the models)

  • make local. The app will be available at 127.0.0.1:5000

To deploy the current version to heroku, do make deploy.

quantified-flu's Issues

Strategy: Which additional data to ask for?

Currently the app only asks for certainty of how correct the date of falling sick is. Multiple people have suggested also adding some details on:

• Symptoms (to maybe see how symptoms are different between Covid-19 and regular flu)
• Different states of disease (cold, confirmed flu, confirmed Covid-19, confirmed ???)

Is there anything else we can think of that would be useful and how to handle the trade-off between asking for too much and having too little information?

UI: Notes for retrospective events hidden

Users can add notes to retrospective events, but this capability is rather hidden as it requires the following steps at this point: 1. create retrospective event 2. open event after creation 3. Click on "Edit event" on the event-page. 4. Write a note.

Ideally the user should be able to write a note already during the creation of the event on the /retrospective/add-event/page.

Improvements symptom reports: Edit/Delete/Add missing

Out of the 2020-05-19 Community Call :

• Existing symptom reports should be editable and delete-able
• Allowing the addition of symptom reports for past days when it was missed

Set Access-Control-Allow-Origin header for API endpoints

As part of his work @basilemorane will start prototyping d3 visualizations in https://observablehq.com. While testing this we noticed that you currently can't use our JSON/CSV endpoints through JS in 3rd party sites due to the lack of Access-Control-Allow-Origin headers on those endpoints.

I'll look into getting those correclty set.

Build Apple Health exporter

Currently we don't have a way for users to get the resting heart rate data from Apple Health into Quantified Flu, which seems like a shame given how many people use Apple Watches to collect HR data.

To enable this we'd need an iOS app that ideally could dump the Apple Health HR data into Open Humans, as we already have the storage infrastructure in place there.

UI: List of retrospective events

This list of retrospective events on the home page for logged in users should be improved:

• The Note about the time it might take to show graphs can be moved to the graph view at retrospective/event/{event_id}, as there are no more direct links to graphs.
• For each events there should be two additional buttons: Edit Notes, allowing people to change the event notes and Delete event to remove the event. Currently both options are hidden away behind many clicks: select view graph -> edit event -> delete events.

Symptom Heatmap improvements

There is a number of small improvements that could be made to the heatmap of symptoms that are displayed on the public reports (c.f. https://quantifiedflu.org/report/list/member/79502270)

• The scrolling currently only works on the dedicated scroll-bar. Ideally any clicking/dragging on the heatmap should allow to scroll as well, as it's very hard to hit that small bar, especially on mobile devices.
• The hover-text for each cell that shows the values is currently inaccessible on mobile devices. Maybe an onClick handler could be added to this to allow this too?
• The display on mobile devices is too wide and doesn't scale with the display (at least not in Safari, see attached screenshot below). Ideally the width would always scale to 100%
• The colors between the legend & heatmap itself are not 100% matching, probably an issue with transparency

Login-button in navbar not always working

While I was playing around with implementing #44 I noticed that the login button doesn't work on all pages, as the URL isn't passed to the template. Here's the pages affected by this:

• https://quantifiedflu.org/public-data/
• https://quantifiedflu.org/retrospective/event/{ID}
• https://quantifiedflu.org/report/public
• https://quantifiedflu.org/report/list/member/{ID}

Order of dates in Apple Health

On the JSON endpoints for retrospective events and symptom reports all data in the arrays is in ascending order (oldest date to newest data), just the Apple Health data is following descending order (newest date to oldest date).

We should reverse in the Apple case to have a standardized behaviour between the different keys in the endpoints.

Thanks to @basilemorane for finding this!

Add support for Garmin wearables

We now got access to Garmin's API and the documentation. The Models for handling Garmin logins (OAuth1) and the functions for accessing & storing the data need to be implemented.

Create alternative data visualizations

Right now we're only showing one kind of data visualization, which is pretty basic. It would be really cool to have more advanced visualizations, not only of the wearable data, but also of the symptom tracking, maybe even in parallel on the same time scale?

One idea would also be to compare your own symptom/wearable data to the complete public data set to put it into larger context/

Set up sentry or similar

A lot of features are untested and potentially hard to test – and our experience has been that we often learn about issues after deployment (i.e. via use). So, we should be catching and knowing about server errors – easier and arguably more effective than focusing on tests.

UI: Expose event certainty

Users are asked to give a certainty rating for how sure they are for the data of a retrospective sickness event. Currently this information isn't exposed on the /retrospective/event/{event-ID} pages. It would be good to add those!

Graphs: Currently no loess fit

The notebooks I made using ggplot2 in R have a nice loess fit for the data points that helps in visualizing things, see https://exploratory.openhumans.org/notebook/83/

I couldn't figure out how to do this with metricsgraphics or d3. Someone that actually speaks javascript would be needed for that :)

Dashboard Re-design

Coming out of the community call on 2020-05-19:

• The Report button is too hidden and should be made clearer for making a daily report
• We should switch the symptom reports & retrospective events so that the reports are on the left, the retrospective events are on the right

Additional physiological data sources/wearables?

Which additional data sources should we try to support? Supporting Apple Watches (see #6) seems like an easy one, but there's probably other widely used wearables that might be useful to support.

Which ones should we add to the list? Please leave a comment here with suggestions!

Large number of repeat `RetrospectiveEventAnalysis` for single `RetrospectiveEvent`

Somehow some of our RetrospectiveEvent objects in production have a large number of duplicate RetrospectiveEventAnalysis objects associated (see https://quantifiedflu.org/retrospective/public for live examples).

I'm not sure how this happened?

Extend parsers to include Fitbit Intraday

Last week I made a notebook that uses both the Fitbit intraday as well as the regular Fitbit data sources to merge them into one nightly HR distribution for more granular data, see https://exploratory.openhumans.org/notebook/85/

The notebook is not practical right now as it runs forever, as I couldn't figure out a smart way to match different date keys and arrays in a clever way. But it would be possible to convert the same approach into a celery task and generate graphs from this.

It should be rather straight forward to adapt the code cells from the notebook to run as an additional parser.

support data from google fit activity

Google Fit data can also come in via the existing activity as data source ("direct-sharing-193") – we should support that too. :) (I think @BenjaminHCCarr might have mentioned this issue, maybe during community meeting.)

UI: Style forms

Currently our form fields are all pretty ugly and not styled at all. That's because the Django modelForm forms don't come with the proper markup that Bootstrap would expect.

An comparatively easy fix would be to add the standard bootstrap code to the forms.

Add display of physiological signals to symptom display

Thanks to the work of @basilemorane we have the beautiful heatmaps for the symptom reports. In the next step of developing this display we want to add the physiological signal (heart rate + temperature) alongside the symptoms as dot plots similar to the retrospective events. They should have a shared x-axis with the symptom reports.

Symptom heatmap on personal list

Currently the Symptom heatmap does not load on the personal symptom report URL (https://quantifiedflu.org/report/list) if the data is not made public. If the data is made public it works without a problem though (see screenshots below).

This is probably due to the fact that the call made to the JSON endpoint to get the data does not contain the user session details that are needed for accessing the private data. Here's the server log when trying to fetch the private data:

4:20:10 PM web.1    |  WARNING:django.request:Forbidden (Permission denied): /report/list/member/07797236.json
4:20:10 PM web.1    |  Traceback (most recent call last):
4:20:10 PM web.1    |    File "/Users/bastian/.local/share/virtualenvs/quantified-flu-eHL-Yns6/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
4:20:10 PM web.1    |      response = get_response(request)
4:20:10 PM web.1    |    File "/Users/bastian/.local/share/virtualenvs/quantified-flu-eHL-Yns6/lib/python3.6/site-packages/django/core/handlers/base.py", line 115, in _get_response
4:20:10 PM web.1    |      response = self.process_exception_by_middleware(e, request)
4:20:10 PM web.1    |    File "/Users/bastian/.local/share/virtualenvs/quantified-flu-eHL-Yns6/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response
4:20:10 PM web.1    |      response = wrapped_callback(request, *callback_args, **callback_kwargs)
4:20:10 PM web.1    |    File "/Users/bastian/.local/share/virtualenvs/quantified-flu-eHL-Yns6/lib/python3.6/site-packages/django/views/generic/base.py", line 71, in view
4:20:10 PM web.1    |      return self.dispatch(request, *args, **kwargs)
4:20:10 PM web.1    |    File "/Users/bastian/.local/share/virtualenvs/quantified-flu-eHL-Yns6/lib/python3.6/site-packages/django/views/generic/base.py", line 97, in dispatch
4:20:10 PM web.1    |      return handler(request, *args, **kwargs)
4:20:10 PM web.1    |    File "/Users/bastian/dev/quantified-flu/reports/views.py", line 193, in get
4:20:10 PM web.1    |      raise PermissionDenied
4:20:10 PM web.1    |  django.core.exceptions.PermissionDenied

I'm not sure how the request here would need to be changed in order to send the necessary data right now though, but it's something to look into.

Expose symptom report lists & JSON endpoints

PR #19 introduced HTML & JSON endpoints at

/report/list/user/{user_id}
/report/list/user/{user_id}.json
/report/list.json

These are currently not linked anywhere from the website. Should link to the public data ones from an appropriate point on the public data site.

Expose additional historical data for retrospective sick events

Exposing more historical data in public sick events

Currently the exposed public retrospectively labeled sick events only give access to a ~2-week window before and after the event.

Additional historical data (3-6+ months worth, possibly even more) is necessary for most prediction and detection models, so that a model, particularly time series analyses models, may feasibly learn what "normal"/baseline looks like. This would also help identify and filter out innate time trends & seasonality within the data (such as temperature & menstrual cycles within Oura data).

A possible user-centric solution would allow the user to select how much data they're like to share within privacy settings. Some considerations around the default settings should be had as well.