Share via

Rich client options

  • Article

Most of our HealthVault documentation on samples focuses on building web applications but you can also use HealthVault with your rich client application.  We support two high-level approaches to doing this:

Intermediate web app

With this approach, your rich client application communicates with a web service that you develop.  That web service, in turn, communicates with HealthVault.  You install a private certificate on your web server and this server performs app authentication with the HealthVault service like any other web app. 

The application authorization process can happen via a page that you host or via HealthVault PatientConnect.  Either way, make sure to request Offline Access in your application configuration.

Software on Device Authentication

Software on Device Authentication (or SODA) is a new option that we added in our 0908 release in September 2009.  With SODA the end user authorizes a device (or client) to communicate directly with HealthVault.  A private certificate gets installed on the user’s PC or phone or other device, and then that device can perform the application authentication step with HealthVault.  The device can then use Offline connections to communicate with HealthVault.  Note that SODA applications will not have a user token and therefore cannot use OnlineConnections.

Each installed instance of a SODA application will have its own unique ApplicationId. This ApplicationId is used by the application instance for all future offline sessions.

The application authorization process includes a few steps that are unique to SODA applications.  Your rich client application must redirect into the HealthVault Shell so that end users can authorize access, but the Shell generally can’t redirect back to your rich client application using ActionUrl because client applications don’t generally host a web component.  This means that you have a few options for getting the user back into your application after application authorization:

  • The simplest approach is to display instructions within your client application that include telling the user to manually return to the application after app authorization is done.  The last screen that the user will see in the Shell looks like this:
    image
  • Build a protocol handler for your client app and register this as your ActionUrl.  HealthVault Connection Center uses this approach so that the Shell can redirect to HVCC after App Auth.
  • After you redirect to the Shell for app auth, have your application poll the HealthVault service until it sees that app authorization has been completed.  At this point your client app can move on to its post-authorization setup steps.
  • If you already have a web presence, build a web app which hosts an ActionUrl that gives specific/custom instructions and guidance to your SODA end users.  You can then also customize the other ActionUrl targets described here. 

If you do not specify an ActionUrl for your SODA app (which we expect to be the mainline case) then you can upload your Terms of Use and Privacy Statement to the HealthVault platform and the HealthVault shell will be able to display these to end users during the application authorization process.  Note that the HealthVualt shell only uses these statements if the ActionUrl is null/empty.  See this post for more details – we expect to change/improve this behavior by mid-2010.

SODA leverages the HealthVault Master-Child application feature, so each instance of a particular SODA application is a child application of a master AppId which you (the developer) control.  In the case of a security issue, Microsoft is able to shut off an entire family of SODA applications with one flip of a switch.

We published a guide to creating your own SODA application here on MSDN.