Extending Q.S. Support in openSNP — Google Summer of Code 2016

Student:Graham Dyer
Contact: gdyer2 at illinois period edu
Organization: openSNP as Open Bioinformatics Foundation
Mentors:Bastian Greshake and Philipp Bayer
Published:22 August, 2016
Modified:06 March, 2017
Status: Final

There were three main features in the proposal:

  1. Write an iOS client to extract health information from Apple’s Health platform.

    Completed as of writing. Codes: https://github.com/openSNP/openSNP-iOS. The app can be called 100% complete as a first version; it functions nicely, and some future interface improvements are clear.

  2. Extend the sever at openSNP.org such that health information can be received from the client.

    Partially completed. An external server written in Python was created to facilitate testing of #1. This server’s functionality is complete in terms of fulfilling the needs of the iOS client. However, this functionality must still must be integrated into the main Rails-based application with the addition of an export/viewing U.I.. Codes: https://github.com/SXibolet/apple-health-demo-server. I will continue working on this during the semester, so we should see the integration running shortly. The reason for the difficulty completing this point is multi-fold:

    • unfamiliarity with Rails and
    • spending time in the beginning of the project on various aspects in the openSNP (see below) rather than this aspect.
  3. Fix Fitbit support, and move on to other devices, if time permits.

    Not completed. This and other features (i.e., dynamic JavaScript-based graphs for new-user sign-ups, phenotype responses & creation, and genotype uploads) were explored in the beginning of the summer, however, Fitbit oauth2 support has still not been added and the graphs, with corresponding rake, haven’t been merged into the master repository. Work will continue on both of these features post G.S.o.C..

openSNP Health

Creating an iOS client to curate Apple Health data was the first goal of the proposal. The result is openSNP Health, which a user downloads (eventually from the App Store) to their iPhone. Work is more-or-less completed on the app. Tweaks and user-interface enhancements are likely for future commits, but a strong first-release has been completed.


openSNP Health, openSNP’s new client for obtaining Apple Health biometrics.

The app’s purpose is rather straightforward: a user of openSNP and the iPhone download the app, login to their openSNP account from the app, and authorize the app to read their Apple Health data. In the background (i.e., the user doesn’t do anything), openSNP Health will upload the user’s newest health data weekly.

Logging in is the first “action” that will be request of a new user. They’ll login via a webview to the server (currently the testing server) where their credentials are verified (the testing server just asks for any unique email address) and a secret key identifying the user. The secret key and the user’s username are stored in iOS’s iCloud keychain service. This allows an easy and secure handoff in case a new device is obtained or the app is deleted.

Authentication is handled via HTTP headers over SSL, where private keys and usernames are stored. Such verification is needed to access all personal aspects of the app: updating the “feed” (last screenshot from the right) and uploading biometrics.

Of course, we use the HealthKit A.P.I. provided by Apple. Upon logging into openSNP from the phone, users are presented with a request to authorize openSNP Health to read their data. Determining the response of this request is slightly tricky: there’s no way of knowing if a user chose not to share a biometric of the 28 requested. Instead, the value for this metric appears as 0, null, or another value that could be interpreted as the user just not logging the attribute. Ignoring such values is not an option: for example, we request access to the number of times a user has fallen, which, if 0, could just mean the user didn’t fall. Thus, it’s currently up to the intelligence of the researchers downloading the data (after the app is made public) to filter these values on a per-variable basis. It’s conceivable we could pre-filter values in the future, or, at the very least, include a prominent warning either in a README downloaded with the data or in the data themselves.

One interesting consideration we had to make was the frequency of uploads. We came to the conclusion that a weekly average with min/max values would be ideal for our current configuration. These uploads occur in the background, and the user cannot force or reconcile connection-failure uploads. When a health-variable changes, HealthKit will notify openSNP Health, which then takes a weekly average and the min/max of the week for the attribute. The downside with the background-type model is that each biometric must be uploaded independently. This has obvious implications for storage and request allocation. The weekly upload policy may be changed in future updates depending on the reaction post-release.

An upload has the form

 1 {
 2         average = 4.6;
 3         "local_timezone_name" = "America/Chicago";
 4         max = 5.5;
 5         min = 3.9;
 6         name = "blood_glucose";
 7         type = HKQuantityTypeIdentifierBloodGlucose;
 8         unit = "mmol<180.1558800000541>/L";
 9         "utc_end_date" = "2016-08-22 22:40:23";
10         "utc_start_date" = "2016-08-15 22:40:23";
11 }

. This upload system is used for 28 HKQuantity subclasses. The 3 HKCharacteristics exposed by HealthKit—Fitzgerald Classification, date of birth, and blood-type—are requested for reading but not currently uploaded or used in another way.

Each time a singular upload occurs, the user’s feed is (permanently) populated with a notice. A near-term improvement is making this notice more useful:

  1. The value of the upload should be displayed.
  2. The name of the subclass should be displayed.
  3. To minimize clutter, uploads should be grouped by week, or only the current week should be immediately accessible.

Error-handling in the app is rather elegant: a cell is display in the feed with alarming colors and some details, including the ability to send an email from the app with the contents of the error if it’s marked as a bug (i.e., it’s the developer’s fault).

Users can logout from the app, which stops all future uploads. They cannot deleted past uploads, however, from either the UI of the testing server nor that of the app. This is a planned in future updates.

Future work & colophon

To summarize and add to the future-work points mentioned above (this list doesn’t distinguish between server or iOS -specific changes)…

    From GitHub Issues: https://github.com/openSNP/openSNP-iOS/issues

    Again, the big-picture items remaining in terms of the all-time-permitting proposal are

    1. the testing-server integration with the Rails app along with
    2. creating a UI akin to that of openSNP’s Fitbit support that allows anyone to download and view data,
    3. submitting openSNP Health to Apple for review and publishing, and
    4. moving Fitbit support to oauth2.

    Beyond this, it would be interesting to look into other smart-devices such as Pebble or Jawbone Up and build clients for them to aid in the discovery of correlations.

    I’d like to thank Bastian, Philipp, and Helge for their support this summer and look forward to continuing to work with them! Vivek & Mateus, it was great getting to know you both!