May, 2011

  • Eric Gunnerson's Compendium

    Dealing with blob data in HealthVault XML


    I recently had a request for more information on dealing with blob data using our newly-released Mobile support, which finally got me to write something about low-level blob support.

    This information applies to any application that isn’t using the .NET SDK to talk to HealthVault. If you are using the .NET SDK, I recommend using the support that is provided in the SDK.

    HealthVault Blob Options

    HealthVault provides the capability of storing additional data – such as documents, images, etc. – as a blob of data attached to any of the HealthVault data types.

    HealthVault provides two ways for applications to manage blob data; an inline method where the blob data is passed with the rest of the data for an item instance, and a streaming approach where blob data is accessed through http get and put requests.

    Inline blob data

    This method passes the blob data in a base64-encoded format with the rest of the item data. It’s the simpler of the methods to use, but it has the following drawbacks:

    • The total size of a HealthVault request has a maximum, which limits the space available for blob data to approximately 5MB (this limit is subject to change).
    • The total size of a HealthVault response has a maximum size, which limits how much blob data can be retrieved, especially if multiple objects with blobs are returned.
    • When the blob data is fetched for an object, data for all blobs is fetched; it isn’t possible to fetch the data for a single blob.
    • Network use will be a little higher and data will be slower since the base64 encoding is a little (about 1/3) bigger than the raw bytes.

    Here’s how you deal with blob data using the inline method:

    Fetching blob data as inline data

    Here’s the “<info>” section of a GetThings request:


    The “<section>blobpayload</section>” line specifies that in addition to the core part of the data item, any blob data should be passed back along with the rest of the XML. If you forget to do that, you won’t get any blob data…

    This query returns a <blob-payload> section that comes after the <data-xml> section:

          <name />

    The following elements are important:

    • name: The name of the blob.
    • content-type: The content type that was specified when the blob was saved
    • content-length: The length of the blob
    • base64data: The blob data

    Uploading blob data as inline data

    Here’s an example of saving a blob as inline data. The blob is passed at the same time the rest of the data for the instance is passed.


    The <data-xml> section is removed for the sake of brevity. The important parts are:

    • name: The name of the blob
    • content-type: The encoding of the data
    • content-length: The length of the data in bytes
    • base64data: The data expressed in base64 format

    Streamed blob data

    In the streamed method, the blog data is fetched or stored using separate interfaces or methods.

    Fetching blob data as streamed data

    Fetching the blob data is simple. If you change the filter to be:


    Instead of the base64data element, you will get a blob-ref-url element that looks something like this:


    You can then download the blob data directly using the URL.

    Uploading blob data as streamed data

    Uploading blob data through the streamed interface is considerably more complex; it requires calling the BeginPutBlob method to get the destination url and then uploading in chunks of data that are a specific size (it also supports signing data, which makes things even more complex).

    If you are interested in using this to load large blobs, let me know, and I’ll try to update this to show that approach as well.

  • Eric Gunnerson's Compendium

    CHC 2011 HealthVault talk, and what is new for HealthVault this past year…


    When we were creating our talk, we had a problem.

    Well, to be fair, we had a few problems, but the problem that I want to talk about is the “for more information” slide, the one that you put at the end to direct people to a location where they can find more information.

    There were actually two problems.

    The first was was that we covered 13 different things during the talk, and there was no way to fit enough information onto a single slide (or even a few slides) to help people out.

    The second was that a fair number (1 “fair” = 6) of items aren’t yet released and this was the first time we were talking about them, so there are no public resources to reference.

    We decided to solve that by doing a “for more information” blog post on the HealthVault blog, which would help attendees find more information and also be of use to those who didn’t attend the talk.

    And then I didn’t remember to write anything until Tuesday night, and had to do a bit of scrambling to get it done. But now, for your reading pleasure, you can read HealthVault at CHC 2011, find out what we demoed, what we announced in the mobile space, and other juicy tidbits of information.

    The conference itself was pretty good, but at only a day and a half tends to feel pretty rushed. We spoke at 8AM on the second day of the conference, second only to the immediately after lunch as a slot that I would like to avoid, but the crowd seemed pretty good, at least, to the extent that I could see them; I tried to look around in the crowd but was a bit hampered by the lights; two searchlights previously used to illuminate Saturn V rockets were aimed directly at my face, and I literally could not tell whether people were standing or sitting; they could all have been wearing clown makeup for all I knew. And if you looked up too much, you’d end up with a bunch of spots in your eyes that made it hard to read your slides.

    Our demo had a lot of moving parts, and it mostly worked correctly. What Vaibhav did was clean as far as I could tell; in my part, the conference center WiFi timed out and I had to re-initiate it during the talk, and I ended up provisioning the mobile application to talk to our practice account, not our live account, but luckily Vaibhav had written the eventing application so that either account worked. Oh, and I had unexpected lack of success with our CAPTCHA, even with the help of others.

    Our goal was to time the talk to 45 minutes, and after answering a few questions during the talk, we finished at 8:52 which is pretty much perfect in my book.

    Please let us know if you have questions or comments.

Page 1 of 1 (2 items)