Right, and in the mean time, while the sensor standards are being worked out, a lot of the action in wireless health today is in mobile applications. A quick search of the iPhone AppStore for HealthVault comes back with three applications developed by AllOne Mobile that connect to HealthVault and one app from Ringful that promises to connect to HealthVault soon. Does HealthVault work with developers to encourage that kind of connectivity to the HealthVault platform?
The funny thing about mobile platforms is that the architecture can be such that really the app on the device, on the smartphone, is a conduit to a separate Web app or service, so the developer’s app is usually talking to their own service. As long as they do that the service as a Web application can easily communicate to HealthVault via XML over HTTP, which is the way we communicate with any other HealthVault-enabled service. Client-side, whether it is on a PC or on a mobile device, direct connectivity to the platform is a little trickier in that the security model has to be tightened up a little bit. We are used to communicating via XML over HTTP and so there are very few client-side sets of bits like HealthVault Connection Center that actually talk directly to the platform.
We are still working on how we incorporate native mobile applications, if you will, to speak directly from an individual phone straight to the cloud as opposed to through a service and then to the cloud. At the same time, it really depends on the business model of the application provider. If a company’s business involves an ongoing service that is constantly connected to a client that is on the phone, say, one that synchronizes a Web version of their service with the phone version of their service, we don’t want to have to step in the middle and say that the phone has to talk directly to HealthVault. I think we will be open and very permissive whether it is direct client-side development or client-through-Web-app. We worked closely with AllOne Mobile with their integration of their service with HealthVault and the wrinkle there is that because it all terminates in a Web service on the back end, it was much more like traditional HealthVault Web apps.
So just to follow-up with a question I received after I sent out a request for questions for this interview on Twitter — Does HealthVault have a roadmap for integrating with the various mobile platforms out there, including Windows Mobile, iPhone, BlackBerry, Palm Pre, Android and so on? Given your previous explanation we may have covered this.
Yes, I think that’s right — for mobile the platform itself isn’t really the point of integration for our service. This is how companies like AllOne Mobile, which can support so many different types of devices on the client end, but then have just one point of integration with HealthVault. It’s not the device talking directly to us, it’s the device talking to the AllOne service and then AllOne’s service talking to HealthVault. We recognize that we will not make an impact on better engaging consumers with their health information unless we are everywhere, so we know we have to be platform agnostic in terms of who can communicate with HealthVault. We want every possible device to communicate to HealthVault, but in terms of a tight roadmap like when will there be an iPhone developer’s kit or an extension to our SDK? I couldn’t say. Obviously Windows Mobile is pretty close to home because we can walk down to the other side of the street and talk to those guys.
Navigation: ( ←Previous | 1 2 3 4 5 | Next→ )