While this post is targeted at attendees of the 18-20 May 2012 Health Hack Day events in Stockholm, even if you’re not attending you still might find some useful Health Graph information and development tips. If you aren’t able to attend in person, you can also watch the livestream online.
Welcome Health Hack Day attendees and hackers!
You’re in for a great weekend of hacking, networking, and fun. And who knows, maybe even a prize at the end!
First up, here’s a copy of our Health Graph programming primer to get you going (click through the presentation and note that links are live):
More details on some key points:
All Health Graph partners are required to follow the Health Graph API Policies.
When you’re ready to get started building a Health Graph API application, visit the RunKeeper Partner page and click “Connect To Our API“. From there you can fill out the form to register your new Health Graph integrated app, service, or device.
Click here to learn about authorization removal callbacks before providing your callback URL on the form. If you will be reading data out of the Health Graph for accounts other than your own app registering account, you should also request Read permission on the form, being sure you give a detailed explanation of what you will do with that data once you’ve accessed it. Likewise, if you would like to ask users for permission to retain their Health Graph data across deauthorizations, please request this permission on the form.
Note: Please include the official event hashtag,
#hhd12, in your new application description and permission justification so we can address your request as quickly as possible.
Need some inspiration to get your developer juices flowing? Check out some of the applications built and deployed using the Health Graph API, available from the RunKeeper Apps page (click here). You can also access an archive of third party libraries, wrappers, and bindings which might make your Health Graph API-based development easier by clicking here. And there’s more information on how app and library partners are taking advantage of the Health Graph via our Health Graph partner profiles series on the blog.
Related content that may also interest you:
- Click here to learn how to export your own user data from the Health Graph; useful for backups as well as parsing your data to re-upload into a test account via the Health Graph API.
- The Healthy button allows you to easily embed the ability to share health and fitness related content on your site or blog into Health Graph users’ FitnessFeeds; click here to learn more about the Healthy button
Now that you know how to use the Health Graph, go build something great and win this thing! Happy hacking!
In honor of our participation in Health Hack Day (@healthhackday) in Stockholm later this week (watch this space for slides and more details), I’d like to feature some European Health Graph (@healthgraphapi) partners over the next couple of weeks. This time, let’s look at how one of our newest strength training partners, Berlin-based Gym Hero (@gymheroapp), is using a streamlined approach to workout tracking coupled with the Health Graph to help people improve their fitness.
Bill Day: Please tell us about yourself and your work.
Gym Hero: We are Jannik and Jannis, the founders of Big Mike Alright, the small but nice company behind Gym Hero. Gym Hero is currently a side project we are working on in addition to our day jobs and college. We both love sports but are especially addicted to kitesurfing!
BD: What is the “elevator pitch” for why someone should use your app?
Gym Hero is a gym workout tracking app that learns from you while staying out of your way as much as possible. The user interface is streamlined and optimized to be used while you work out, even with shaky hands. Workout routines are automatically learned as you go, so you never have to enter a weight or name twice. You are free to name your workouts and exercises however you like – full flexibility instead of endless searching and browsing in predefined, fixed lists. Each of your workouts gets its own webpage (if you want) with all the details, so you can share, compare and discuss with friends.
BD: How did you get started using the Health Graph API?
We both have been using Runkeeper tracking for our cardio activities for quite some time now. Being data and statistics junkies, our weight goes into the Health Graph via a Withings scale, and our blood pressure is monitored and sent to the Health Graph via a Withings blood pressure monitor. We track our runs and the bicycle commute to work with RunKeeper.
Because we also love to work out we wanted to add our gym workouts to our Runkeeper profile as well. When we heard about the Health Graph API we wanted to join. Quantify yourself!
BD: How is using the Health Graph benefiting Gym Hero and your users?
The Health Graph community is a place where sports enthusiasts of all types meet to motivate each other, exchange, discuss and most of all track and measure their performance. It’s a great place to collect all your sports and health related data. So obviously, we wanted to allow our community to join the Health Graph family and vice versa.
And for the programmers reading this: The Health Graph really is easy to use and embed into your applications. Go try it out!
BD: Which portions of the Health Graph API do you use, and why?
Since Gym Hero focuses on doing one thing only, but doing it really well, we use the strength training portion of the Health Graph API. We feed full workouts including workout notes and exercise names into the Health Graph. We don’t track cardio or time based training (yet).
BD: What do you like about the Health Graph? What would you like to see changed?
We love the idea behind the Health Graph. Bringing together such a great variety of health data is simply awesome. On top of that it’s a breeze to integrate into other applications. Just keep up the great work!
BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?
We would like to see a little more flexibility when it comes to defining muscle groups for each exercise. Our basic idea for Gym Hero is to give our users full freedom in naming their exercises/workouts. We would love for this to also be possible for muscle grouping.
BD: Can you share any future plans for your app? What’s coming next that your users will be excited about? Does the Health Graph play a role in that, and if so, how?
We’ve been updating every five to six weeks with new features and improvements, but there are a lot of updates still to come. We will extend the workout summary view for a better performance check, add data sync with iCloud and a workout timer to name only a few upcoming features.
Our users can also request and vote for new features. They can do this by clicking on the speech bubble in the app or by going here. Please help us build the finest workout app ever by making your requests. We love to hear from our users!
BD: Is there anything else we should know about you or your application?
If you want to track your gym activities and are looking for a slick app which is not blown up with useless stuff check out Gym Hero. Never leave without flexing!
It’s been almost a year since we launched the Health Graph API. We’ve learned a lot, and based on that learning, we’re making some changes to our API policy to make it more user-friendly and more partner-friendly as we continue to grow.
A bit of history
The goal of the Health Graph is to give consumers one place to store, correlate, and understand their Health and Fitness data. Two of our core beliefs around achieving this goal:
- Users should have control over their own data.
- Data integrity is paramount to providing meaningful insights.
As a part of our implementation of these beliefs, a core tenet of our existing API policy has been that when a user disconnected their account from a third party partner application, service, or device, that partner has been required to remove all data that had previously been read from the Health Graph on that user’s behalf. The idea being that by requiring partners to remove that data, we were insuring that user data didn’t become siloed somewhere against their wishes.
While our core beliefs around data control (users should be empowered) and data integrity (everything should be kept in sync) haven’t changed, we’ve learned that our execution on them wasn’t perfectly aligned with the needs of users or partners.
- For users, we didn’t provide an efficient mechanism for them to export their data out of our system.
- For partners, the relationship wasn’t reciprocal – data written to the Health Graph was stored until a user explicitly deleted it, while data read from the Health Graph could only be cached as long as a user maintained a partner app’s authorization.
- For both parties, the policy meant that disconnecting from the Health Graph had the potential to destroy the experience for users with the partner’s application.
We recently addressed the first user concern by providing an easy mechanism for users to export data from their RunKeeper account. We’ve been receiving and implementing great user feedback on the export functionality; please keep it coming!
Now we’re addressing the additional concerns around data retention through an updated API policy and new functionality to support these updates.You can read the entire policy here, but the primary update boils down to this: If a user gives a partner permission upon disconnecting their service from the user’s Health Graph account, that service can retain any Health Graph data they have previously cached on that user’s behalf, indefinitely.
How this change works in practice:
When a user goes to disconnect a service from the Health Graph, they are now prompted to confirm this disconnection in a modal window (see below). As part of this confirmation, they are also given a choice of allowing the partner to keep data previously obtained through the Health Graph.
The user’s choice is passed through as part of the deauthorization callback described here.
What about my (Existing) integration?
Nothing has to change with your application. If you had previously requested permission to read data from the Health Graph, you can cache Health Graph data and remove it when a user disconnects. However, if you would like to take advantage of our updated terms around data retention, you’ll need to make a couple small changes to understand a user’s data retention request via the updated callback, or new deauthorization service mentioned in the previous section. You’ll also need to update your application settings to enable this data retention request.
One more thing…
We also totally revamped our Health Graph support docs. While the aesthetic changes are great, we’re really happy to be including basic search functionality, improved readability, and better access to our developer resources. Stay tuned, because a functional developer console is coming soon as well.
Thank you for all of the great feedback you have provided, which led to these improvements. Feel free to provide any additional feedback in the comments below. We can’t wait to see all of the great integrations that are to come!