HealthVault FAQ

Recognizing that a file is a CCD

Tremonte — Mon, 22 Jun 2009 21:54:00 GMT

If an end user uses the "Upload a file" workflow in the HealthVault shell (https://account.healthvault.com/viewitems.aspx?typeid=bd0403c5-4ae2-4b0e-a8db-1888678e4528&additem=True) to upload a CCR or CCD file, the HealthVault shell recognizes that the file is a CCR or CCD and stores a CCR or CCD item to the record instead of storing a File item.

This logic is part of the Shell and gets exercised at the application layer. So if you write your own application which writes new File items to a HealthVault record, this logic will not get applied to your uploads. CCR or CCD files that you write with the File typeId will get stored as Files.

In a nutshell: the Shell can recognize that what the user thought was a File should really be stored as a CCR/CCD. The platform does not perform this check before storing a File item.

Identifying data type versions

Tremonte — Fri, 10 Apr 2009 23:34:00 GMT

Some of our developers have asked how to identify the most recent version of a HealthVault data type that has been revised. We are working to improved our naming conventions and documentation in this space, but until then here is a workaround:

Go to the HealthVault Data Type Schema Browser at http://developer.healthvault.com/types/types.aspx
Click on each version of your data type
Look in the "transforms" list for an "upconversion" transform and/or a "downconversion" transform. The former means that newer versions must exist and the latter means that older versions must exist. So look for the type which has only a "downconversion" transform and you'll have found the newest version.

Here is a list of the data types that have been revised as of today:

Family History:

6d39f894-f7ac-4fce-ac78-b22693bf96e6 is the first version and is listed first
22826e13-41e1-4ba3-8447-37dadd208fd8 is the second version and is listed second

Immunization:

cd3587b5-b6e1-4565-ab3b-1c3ad45eb04f is the second version but is listed first
3d817dbe-af42-4a9d-a553-d1298b4d08fc is the first version but is listed second

Medication:

30cafccc-047d-4288-94ef-643571f7919d is the second version but is listed first
5c5f1223-f63c-4464-870c-3e36ba471def is the first version but is listed second

Procedure:

0a5f9a43-dc88-4e9f-890f-1f9159b76e7b is the first version and is listed first
df4db479-a1ba-42a2-8714-2b083b88150f is the second version and is listed second

Encounter:

3d4bdf01-1b3e-4afc-b41c-bd3e641a6da7 is the first version and is listed first
464083cc-13de-4f3e-a189-da8e47d5651b is the second version and is listed second

When trying to configure your Application Configuration Center, you will not be able to see these GUIDs but the HealthVault platform returns the data type list in the same order each time so you can use the reference chart above to make sure that you are requesting access to the right data types.

HealthVault platform exception: “The specified transform was not found.”

Tremonte — Wed, 18 Feb 2009 00:39:00 GMT

If you see HealthVault platform throw the above exception when you run HealthRecordSearcher.GetMatchingItems() with specified type ID, the likely cause is that the locale of the application server is set to a value that doesn’t match the locale of the XSLT transform in HealthVault platform. The platform then fails to retrieve the XSLT transform with the application server’s locale. To work around this, we can add an element in Web.Config to specify the locale.

<system.web>

</system.web>

</configuration>

When debugging issues like this, the request-response tracing described at http://msdn.microsoft.com/en-us/healthvault/cc135993.aspx should be quite helpful.

Energy Burn from Pedometer Data

Tremonte — Wed, 18 Feb 2009 00:32:00 GMT

With the release of HealthVault 0901 (late January 2009), applications that access data uploaded from Omron 720ITC pedometers are no longer able to retrieve a value for calories burned during exercise.

Applications that use the Exercise data type (the replacement for the AerobicSession type in the 0901 release) are impacted by an issue with the Omron driver, where the driver uses the incorrect detail type (Work_kj rather than CaloriesBurned_calories) to report calories burned. When an updated driver is available, this value will be available in CaloriesBurned_calories. Since users will not be automatically updated to the new driver, this issue may continue for some time. Applications can work around this problem by falling back to Work_kj if there is no value for CaloriesBurned_calories. NOTE: Applications will also need to handle the resulting unit mismatch (since Work is expressed in kj, and CaloriesBurned is expressed in calories).

Applications that use the AerobicSession data type are impacted by a different problem. As described in the blog post on using the Exercise type the Energy property in AerobicSession had an ambiguous definition. HealthVault cannot deterministically down-version a calories value from Exercise to AerobicSession since the Exercise class has two different details for calories and work done, whereas AerobicSession has only one. The fix is to upgrade to the new Exercise type, with the caveat that calories may not be available in CaloriesBurned_calories until an Omron driver update is released.

We will update this blog post when the new Omron driver is released.

EDIT (18 Feb 09): The updated driver has been released! When you uninstall your old driver and install the new one you should see that it is version 1.5.0.0.

Debugging proxy issues

Tremonte — Fri, 30 Jan 2009 19:17:00 GMT

Your web server is usually happy to respond to requests from outside users but is often not configured to initiate calls to an outside service like HealthVault. Your proxy/firewall needs to be configured to allow this type of traffic. The specific configuration steps vary depending on which software your company uses, but there is an easy way to determine whether you are having an "IT Issue" or an issue with your HealthVault application: open a web browser on your web server box and try to access either of the HealthVault URLs that are in your web.config file.

If you can reach either URL, then your proxy is set up correctly and you need to adjust some aspect of your application configuration. The most common fix is to uncomment the <DefaultProxy/> node in your web.config file, assuming you are using the HealthVault .NET SDK.

If you cannot reach these URLs then you should focus on getting the proxy set up rather than pulling your hair out trying to change up your app configuration.

Microsoft.Health.HealthServiceException: The unique identifier for the person cannot be '00000000-0000-0000-0000-000000000000'.

Tremonte — Sat, 24 Jan 2009 00:15:00 GMT

A few application developers have seen this error message when trying to read data from a HealthVault record using an OfflineConnection. Here is a code fragment which could generate this error:

OfflineWebApplicationConnection offlineConn = new OfflineWebApplicationConnection(personGuid);
offlineConn.Authenticate();
HealthRecordAccessor accessor = new HealthRecordAccessor(offlineConn, recordGuid);
myName = offlineConn.GetPersonInfo().Name;

My first thought is always "did you remember to set both the RecordId *and* the PersonId when setting up your connection?" But in the case above both appear to be getting set. So the most likely cause is an outdated entry in your web.config file which is causing you to point at a different environment than you intended (i.e. HealthVault-PPE instead of production HealthVault). So the guid pair that you're requesting doesn't exist ... and you can't possibly be authorized for a non-existent guid pair.

Check out this excerpt from the How-To article on Offline Access,

“The Authenticate() method authenticates only the application, not the user. So if you send an incorrect UserID (or a RecordID instead of a UserID), you don't see an error message until you actually try to read data.”

So you thought that your call to Authenticate() succeeded in authenticating your {RecordId, PersonId} pair but in reality all that got authenticated was your application itself (via the HealthVault asymmetric key infrastructure). When the GetPersonInfo() call was made and the record authentication failed, HealthVault sets your PersonId to all zeroes and returns the message above rather than saying "Access Denied."

We continually strive to make our platform error messages more clear ... but we can update this blog a lot faster than we can ship new code.

Live ID Reserved Domains

Tremonte — Thu, 25 Sep 2008 22:48:00 GMT

If you or your users are running into this error when trying to create Live IDs, read on.

The portion of your e-mail address that follows the @ symbol is part of a "reserved domain" such as live.com, hotmail.com, msn.com or passport.com. Please type a different e-mail address.

The HealthVault sign-in process exposes a "Create a Live ID" link for users who don't already have one. But there are two different ways to create a Live ID that are worth knowing about:

You can wrap an existing email address with a Live ID. This is referred to as an EASI Live ID by the technical folks but you won't see this term in consumer-facing pages. You can wrap any email address with an EASI Live ID as long as that email address isn't on a "managed domain" like hotmail.com, verizon.net or msn.com. Addresses on these managed domains already *are* Live IDs so wrapping doesn't make sense. If a user enters an email address on a managed domain into the account sign-up box then they will get the error message above.
You can create a new Live ID from scratch. This new Live ID will come with its own Hotmail inbox. HealthVault used to expose this option within the sign-up flow but it added extra screens & confusion to the process so we pulled it out. You can still direct your users to that workflow via http://get.live.com/getlive/overview.

So if you see this error you are probably trying to do one of two things:

If you are trying to turn an existing email into a Live ID then chances are that email already *is* a Live ID. If you don't remember the password for this Live ID anymore, you can either reset it (https://account.live.com/ResetPassword.aspx) or go create a new one.
If you are trying to create a new Live ID then you should go to http://get.live.com/getlive/overview instead.

My app was working before but now i get access denied

vaibhavb — Fri, 06 Jun 2008 05:52:00 GMT

Several folks have run in to issues, where their application was working fine at some point and now they see an error like -

[HealthServiceAccessDeniedException: Access is denied.]
   Microsoft.Health.EasyWebRequest.WaitForCompletion() +438
   Microsoft.Health.EasyWebRequest.Fetch(Uri url) +150
...
   Microsoft.Health.AuthenticatedConnection.Authenticate() +79
...

The cases typically are-

The application was working fine in PPE (pre production environment) or Production environment and you recently did some certificate key-pair (typically makecert) operations, and/or sent a new public key to Microsoft.
The application was working fine in PPE and now you moved to Production with new certificate.

Also, a likely culprit is that you are using the same server for targeting the PPE and Production environment.

So, what's the big mystery behind all this? Well, the essence is that your private key being used for the web application doesn't correspond to the public key which is configured in the Microsoft environment.

How does this usually surface? Well if you use the Application Manager from the HealthVault SDK on the system running your webserver (you might have to uncheck the box "show unnamed applications"), you will see more than one certificate associated with your application id (WildcatApp-<your_app_id>). So what this means is that you are confusing the HealthVault SDK on which private key to use to talk to the HealthVault platform and yep! the wrong one is being used! Hence the access denied!

So what's the solution? Know your keys! Guard them and yep! make sure that there is only one private key on the server associated with your application and its being used against the correct public key / environment. You can achieve this by deleting and moving out the irrelevant keys from your key store.

Can I develop HealthVault applications using something other than .NET?

ericgu — Wed, 14 May 2008 16:54:00 GMT

HealthVault is an XML-based API that is accessed over https and can be called from any platform that supports that approach, but there are caveats to doing so.

You should start by reading our announcement to understand how we are approaching this area.

The following libraries are currently available:

A Java library (CodePlex)
A Ruby library (CodePlex)
A Ruby library (RubyForge)
A PHP library (SourceForge)

All of these libraries are currently in an early state of development, and partners that use them are likely to be writing a fair amount of library-level code themselves. There are a few things that we're doing to make that process easier:

The libraries we've released contain some of the hard code around authentication, and we will consider doing that for other platforms based on partner interest.
We are releasing the source of the .NET libraries in the near future, which should make developing similar libraries much easier.

We are also working closely with selected partners who are going down this route, and will consider working with others on a case-by-case basis.

How do I access the schemas for HealthVault data types?

ericgu — Fri, 09 May 2008 16:14:00 GMT

There are several links to schema information on the MSDN site in the learn tab.

If you want to access them programmatically from the platform, this post will get you started.

Are the SDK samples available in VB?

ericgu — Thu, 08 May 2008 22:14:00 GMT

Currently, all of our samples are available only in C#.

If there is sufficient partner interest in us providing the samples in VB as well, we will consider doing that, but for now we are focusing on expanding our sample set and improving our documentation.

My app does not work after turning on SSL

vaibhavb — Sat, 12 Apr 2008 01:18:00 GMT

If your application is working fine before you configure IIS to use SSL, make sure the following is set in your web.config (under configuration\appsettings):

We recently ran in to some of our application solution providers having this problem due to WCPage_SSLForSecure being set to false. A more detailed documentation of various Web Configuration options is in SDK help.

XPS files and the .net framework

Tremonte — Wed, 26 Mar 2008 21:01:00 GMT

Much of the HealthVault SDK documentation uses the XPS file format. If you do not have an XPS viewer installed then you may be prompted to install an updated version of the .net framework in order to view the file. This step would be sufficient but isn't necessary -- you can get just the viewer from http://www.microsoft.com/whdc/xps/viewxps.mspx.

Where do I put my bits?

Tremonte — Fri, 08 Feb 2008 22:50:00 GMT

An application developer recently asked how much of a HealthVault-compatible application and its data are hosted on Microsoft servers versus servers that the developer maintains. Here is an answer:

The application resides on a server that you maintain
Consumer health data resides on a HealthVault server. Your app server can read from and write to this server at run-time (using the HealthVault web service) as long as the user has authorized this access.
If your application also maintains non-health-related user data, you would store that data on your own server.
You may copy consumer health data onto your own server (provided your app has been authorized to read this data) but you are not permitted to transfer that data onward without explicit opt-in consent from the user. This still applies if you aggregate and anonymize the data. HealthVault is very serious about protecting the user's privacy.

Please use the comments below or the forum if you have questions.

Troubleshooter: Error accessing site

ericgu — Wed, 12 Dec 2007 22:31:00 GMT

This error occurs when the troubleshooter cannot access a specific site.

If the error occurs when trying to access Microsoft.com, this could indicate generate network problems, or it could indicate a proxy issue. The web.config files in the samples contain a defaultProxy setting that can be enabled to use a proxy.

If the error occurs when trying to access one of the HealthVault servers, it could be a proxy issue, or it could be that the values for ShellUrl or HealthServiceUrl in the web.config are incorrect.

For the Developer server, these should be as follows:

and for the Consumer server, they should be as follows:

Note that both of the urls use "https" rather than "http".