Updating HealthVault Data - Best Practices

Feb 3, 2011 at 5:29 PM
Hi, HealthVault GETTHINGS method returns a lot of additional data items that our application does not use. For example – in immunization, the user can input data such as who administered the test, location, which body part was it administered to, etc. These data are not used by our application and never displayed to the our application user. When a user edits this data item using our application UI, if we do not store the additional data, it will be lost to the user. So to avoid any loss of data - we can use one of 2 approaches. 1. Store the complete data set in some sort of staging table and use that data to recreate the complete data set. Update the data set with the new values captured through our application UI and update HealthVault. 2. Alternately, we can retrieve the data at the time of update, make the necessary updates, and send the data back to HV to update the user data. The second approach could have performance issues (since we are opening a connection to HV twice from our application). I just wanted to find out what Microsoft HealthVault team recommends as the best practice in this case. Any suggestions? Also - is there a way to manage a connection pool to HealthVault? Is that a best practice? Thanks Shyam
Feb 4, 2011 at 6:34 AM
Edited Feb 4, 2011 at 10:58 AM

Hi Shyam,

I'm happy enough to answer the question about updating data, but questions like those are probably best posted to the HealthVault developer forums.  They apply to all users regardless of SDK.

That said, updating is rare...very rare in practice.  I wouldn't worry about the performance aspect.  Retrieving the most current thing version is appropriate for several reasons including concurrent access and version conflicts.  Things should be treated as a unit and updated as an entire entity.


The "Connection" class may be a little bit of a misnomer.  Your application is authenticated once and it's access credentials are cached to be used across your entire application at the same time.  Creating a connection from the factory is then super light weight.  Only when you make a request is an HTTP connection used.  It's not like opening up a database connection. Connection objects themselves, however, are not thread safe and should only be used by a single thread at a time.

Underlying the connection is a Transport object that does the dirty work of managing HTTP connections.  By default, connections use the URLConnectionTransport class which utilizes java's URLConnection class.  These connections may be pooled as documented here:  http://download.oracle.com/javase/1.5.0/docs/guide/net/http-keepalive.html

There are many high traffic applications against HealthVault that close the HTTP connection between every request.  I would evaluate first if you really need to pool them.




Feb 7, 2011 at 6:30 PM
I did post this on the HealthVault forum and I received a similar response - at about the same time. Thanks for getting back to me. We are going to retrieve data at the point of update and send the updated data.