HealthVault Data Types – Weight, measurements, and display values…

In this post, I'd like to discuss a bit more about the HealthVault data types. The types all live in Microsoft.Health.ItemTypes.

(as an aside, you may come across mention of "thing type" rather than "item type". They're the same thing)

As an example, we're going to look at the Weight type, which represents a person's weight.

When we look at the docs, looking for a weight type, we find something that's a bit weird. There is a Weight item type and a WeightValue item type. The explanation of why there are two types and the differences between them will require a bit of an aside, but we'll get back to Weight in a little bit.

One of the problems that the API has to deal with is the fact that there are different units for a single measurement. So, for distance we might want to keep track of distance using meters, but in some cases our users want to enter distances based on miles. So, we write a few conversions in, and when the user enters:

24 miles

We convert that to meters, and store that value. And whenever we need to show that value, we convert it back to miles. But there's something we've forgotten.

Namely, we've forgotten that floating-point numbers aren't exact, so that in certain cases, that two-way conversion may be lossy. So, a user might enter:

24.81 miles

and then have the program display

24.80999999 miles

which is wrong. Or at least confusing.

The HealthVault API deals with this by adding the concept of a "Display Value". So, when we want to store a value that is 24.81 miles, we store that exact text in a DisplayValue instance, and the converted value in meters. Applications that need to display the value use the DisplayType version, and those that need to do calculations will use the value in meters.

That concept of having a display value and being a measurement is encapsulated in the Measurement<MeasurementType> generic class. Derived from that are the following measurement types:


(don't talk to me about the lack of naming consistency...)

So, the WeightValue type is an abstract measurement of weight, and the Weight type is the weight of a person. 

Back to the weight type, which really isn't that interesting any more, because I've covered most of the important stuff.

If you look at the Value property, you will find that it's a WeightValue type, containing the weight in kilograms and the association display value.

One other field is the When property, which stores the time at which the weight measurement was taken. Unlike EffectiveDate, this field allows modification and is therefore more flexible.

Comments (5)

  1. Jon Skeet says:

    I maintain that the numbers are exact, it’s just the conversions which are lossy. Anyway, moving on… why aren’t they just stored as decimals? Are there values which can’t be exactly stored as decimals?

  2. ericgu says:


    I don’t think decimals get you anything that you don’t get with strings, and you’d need to do a conversion into string to store it in the database (and transmit it across the wire as XML).

  3. Chris Varro says:

    When you use decimals you don’t have the floating point ‘lossy’ problem.  Doesn’t this take away the need for a "Display Value"?  Or is does this just move the problem to the db layer?

  4. HealthVault says:

    I wrote a few articles about data types on my blog: HealthRecordItem Weight, measurements, and display

Skip to main content