SODA Application

Jun 29, 2011 at 5:28 AM


Is this type of application supported by the java library? If so, is there any example for that (if any specific set up needs to happen)? I can see a SodaAppConfig class in the java library but I am not sure how to go about using that, any pointer is greatly appreciated.



Jun 29, 2011 at 10:42 AM

There is SODA support in the Android library.  What environment are you hoping to run SODA?


Jun 29, 2011 at 12:51 PM

Hi Rob.

The main environment I am interested in for SODA support is not Android (at least not yet :-)), it is a normal environment (a Linux box that is kind of like an embedded device inside the home). Is SODA supported in general, and if so, is there any documentation as how I should set things up when I create the master application, what keys need to be put where (private and public), what the SodaAppconfig class is used for, etc?

Many thanks,


Jun 29, 2011 at 11:30 PM
Edited Jun 29, 2011 at 11:31 PM

With SODA you do not need public/private keys.  The authentication model uses a shared secret.  The user needs to interact with Shell to establish a unique shared secret for each installed instance.  The Android sample works this way and you can use the same model for a Linux client. 

Ths SodaAppConfig class isn't exposed in any public method.  Instead use Application Config Center at to create a master soda app.  You will need to assign the authorization rules you want all the client app instances to have.  You will use this master app id when you call NewApplicationCreationInfo. 

The model goes something like this:

1.  Client calls NewApplicationCreationInfo(masterAppId) to obtain an instance AppId, an authentication secret, and a token to be passed to Shell so that a user can create and authorize the application in HealthVault.

2.  Client calls GetAuthorizedPeople to get a list of PersonInfo objects representing the people and records authorized.

3.  Client uses offline access to access the record.

Dec 30, 2011 at 10:37 AM


This is not how I understand it. This is what Microsoft says about the first stage of a SODA application

The Application Manager automatically performs the following steps:

  • Creates a new application with the Default application type.
  • Creates a public/private key pair.
  • Adds the private key to the local certificate store.
  • Uploads the public certificate to the PPE.
  • Assigns the public certificate to the new application.
  • Opens the PPE Application Configuration Center in a new browser window.

I am currently getting involved in a java-based HV application and am finding it very frustrating to figure out how it works. It appears that there is some universal application ID which is assigned to the application by MS. Maybe $$ are involved to get that ID but I am not sure. Then a user needs to authorize this application to access their Personal Health Records (PHR). In that process a private key is created by the application for the user (not the application) So if the application supports N users, a private key is created for each user. From that private key a public certificate is created. This public certificate along with the application ID is then passed to the user's PHR. When the user gives permission one can see that computer in a list when visiting the PHR. The application has to store this private key for each user. It also appears that the application gets a uuid for this particular user which it must associate with the private key. Little confused about that. IN any case the above is a one time deal. Of course if the same application is used on another computer the process has to be repeated. One will see in the PHR the application for both computers now in the list.

Once this is done the user can access data or send data to the PHR using the application.

When the user of the application wants to send data to the PHR it appears the application first needs to get a list of users that the application has been authorized for. Not sure why this step is necessary given that HealthVault already has the public key and application id for the user which, by definition, uniquely identifies the user. But it appears that it is. So then one needs to find the proper user from this list of authorized users apparently by looking for that uuid retrieved during sign up. With that one can now user another API to send data to the PHR.

I am still confused about this (to me) illogical step of getting a list of authorized users when I already have the user's private key. In fact, there are lots of things I find confusing about the HV interface. The MS examples all use NET and Visual Studio which does so much under the hood its hard to figure out what needs to be done in the Java environment where all those details have to be done manually.

Dec 31, 2011 at 6:22 AM

Hi Brian,

I'll put aside the SODA vs. Web Application issue and first concentrate on how to create a new application in HealthVault.  There are some instructions here, but they are getting a little dated.  You can create new applications directly in a self service web page bypassing Application Manager completely.  Navigate to, login and create your application.  Upload your public key and your application is live in the Pre-Production Site (PPE).

Now I'll talk a little about SODA vs. Web Applications:


Soda (Software on Device Architecture -- a bit of a stretch in the acronym department) applications are meant to run on devices such as PCs, mobile phones, whatever.  Typically, these applications service a small number of users and quite often just a single user.  The applications are identified via a shared secret and do not use PKI.  The user must log into HealthVault a single time to authorize the application.  Soda applications must then query HealthVault for their authorized users and/or store the users ids locally.  Authorization happens out of band from the application.

When creating a SODA application in HealthVault, first a SODA master application must be registered via  This application is never directly authorized, but serves as a configuration repository for all SODA applications created from it.  Each SODA application on each device will have it's own distinct application identifier. 

Web Applications

Web Applications typically serve N users.  They authenticate themselves with HealthVault via PKI.  Users interact with HealthVault and the Web Application interactively--online.  Online access means the application is authenticated and possesses an authentication token, and the user has authenticated to HV and their authentication token has been forwarded to the Web Application.  The two authentication tokens together allow the Web Application to access the user's data.

If the Web Application has been authorized for offline mode, the application does not need to present a user's authentication token to HV and instead simply provides the user's person-id. 

I hope this helps,


Feb 10, 2013 at 10:38 AM
Thanks Rob (delayed). After working with HV for a bit I am starting to catch on. This did help toward that goal.