There have been a lot of interesting developments lately in the area of devices and web APIs that are clearly only early steps, but have struck me as collectively representing building blocks towards the digital nervous system concept I presented in my (stammering) talk at Ignite Hampton Roads a few months ago. My basic premise there was the idea that the various devices, apps, tools, and platforms we’re using and that are coming could act as a sort of augmented “nervous system” to learn more about our active bodies and expose our health information to others. My own interest in this idea was driven by my problems with my own nervous system, which I still deal with and which continue to deteriorate.
Connections
Most recently two separate teams announced projects centered around the idea of a “personal,” or “human” API (application programming interface), representing a person’s health and activity data in a common, easy-to-understand format. The Human API is a project that has released little information but has a planned hackathon/launch event this month and gained significant reception based on a single, simple example. It seems to have resonated with people.
Similarly, FourSquare co-founder Naveen Selvadurai posted about his own “personal API” idea and made available his own data to anyone with a Twitter account.
The flip side of presenting all this data is collecting it, and that’s where some exciting (though flawed) technologies are showing up in the hardware space. In addition to all the existing popular health and activity trackers, there were two devices announced recently that specifically seem to feed into this idea of a digital nervous system – W/Me from Phyode, and the Bandu. They both need work but I’m fascinated by the attention to the autonomic nervous system and the potential there when combined with the simple but powerful idea of body APIs.
These general ideas are something I hit on in my presentation back in October – the idea that we can have an API that exposes the raw information about our physical bodies, with devices that record that data directly from our nervous system.
[youtube=http://www.youtube.com/watch?v=xzBLuQiXsUU]
(Although pleased with the presentation, it’s hard to explain just how strenuous it was because of my tachycardia issues. I hinted at it a bit during the talk, but it might be better illustrated by the image of my heart rate I captured while speaking.)
I actually edited out a lot of my ideas about the application of these concepts to APIs and REST to gear it towards the non-technical audience on hand (and it might still have been a bit too technical), but people I talked to got the overall concept, but more importantly appreciated my willingness to share my story and the details about my challenges, and potentially even my data. It told me that there was interest in these ideas, which I think has really been validated by the excitement I’ve seen for these new announcements on Twitter and elsewhere.
This general web API idea is of course something I’ve been working on myself – before and since my talk – as part of a platform for collecting symptom data and correlating it to biometrics. So I’m keenly interested in what comes out of these other projects and how they’re used. But based on that fact, I also hope the various projects can work together to develop these formats as open standards for anyone to develop to and against. An API of this nature should not be owned by a single gatekeeper company. We don’t need a Facebook for our own bodies.
The Next Level
But the biggest limitation I see in all the platforms and ideas I’ve mentioned above is that they represent static information. What I really want is to see developers think big and put these ideas on steroids – there’s little limit to how far these concepts can eventually go, especially considering both the advances in real-time recording of biometric data using wearable and implanted devices combined with better and better mobile data connections and real-time web technologies like web sockets. Hook it all up, make it available, make it real-time.
I don’t want to share my heart rate data. I want to show you my heart beat, right now. I want to show you the severity of the tremors I’m experiencing right now (no really). Maybe peek into my blood stream.
Consider the relevance of that kind of real-time information for your own understanding of what’s currently happening with your body (during fitness, work, family activities, or in my case, just physically trying to get out of the bed or stand up from a chair). But also consider the value for remote monitoring of patients by family, caregivers, and health providers.
All these pieces, while interesting to some, have the potential to present breakthroughs in the realm of chronic condition care and understanding, but few products appear to recognize this significance or choose to avoid it. Devices listed on Kickstarter deliberately downplay their relevance to health to conform to Kickstarter’s rules. APIs and tools are often created by developers and engineers with an interest in fitness or general health, but with no real understanding or insight into the kinds of insight patients with chronic illness are looking for. I’d really like to see these ideas oriented more towards the people that can truly be helped by them, by leveraging these designs to develop tools that help those people understand themselves more and get the care they need.
And while security and control of one’s own data is crucial, hopefully patients and others will be open to the possibilities presented by sharing their information with their friends, family, and doctors, or even with the public. I expect as our cultural norms evolve, it will eventually become clearer for many that the potential benefits of sharing one’s data far outweigh any risks involved.
Virtual Humans
When combining devices with the underlying architecture of the web itself, we have the potential to realize what Dr. Eric Topol calls the “virtual human being” in his seminal book:
“When we put all of these capabilities together, we have created a virtual human being that, although not real, replicates many of the individual’s essential characteristics.”
– Dr. Eric Topol, The Creative Destruction of Medicine
We’re still a long way from that goal, but maybe not as far as people might think. The future is flying towards us faster and faster as more of these ideas and products are unveiled and people recognize the potential.
There’s a feeling of things racing forward. Synapses firing. Neurons connecting.
Edit: Re-added a paragraph about data privacy vs. sharing I somehow lost in editing.
More editing: Removed some thoughts about REST to make this a bit less technical. I’ll put them in a later post.
[mc4wp_form]
Having access to (near) real-time data opens up a lot of interesting opportunities, but standards like the Bluetooth LE profiles seem much simpler and more reliable than Web APIs for that purpose?
Web APIs are great for long term storage, analysis and sharing. I agree that we don’t need one service “to bind them all”, but don’t see the need for Quantified-Self-specific standards, either.
Projects like the human API would be less necessary if companies put a bit more thought into their APIs, instead of treating them as non-revenue-generating checklist features.
I call this “existence as a platform” the idea of sharing your “digital self” taken beyond medical only creates a “social GPS” http://www.slideshare.net/chrisdancy/existence-as-a-platform-where-quantified-self-meets-internet-of-things
Thanks for posting the slides Chris – really interesting stuff. I definitely like your terminology, and I’ve been really interested in your work since reading the Wired article. I saw your other message and will be in touch!
Eric – I agree the Bluetooth LE profiles will be incredibly useful for collecting the data from the devices, but then routing that information onto the web opens up a whole world of remote monitoring and live sharing.
I’m a little mixed about the standards point myself. I’d like to see a standard, but it might also be good just to have a set of best practices around these ideas – with the goal being to create APIs that are really thought out and designed to reflect the real raw data of the human body, not the checklist features as you put it. So I think I generally agree. 🙂