In my previous posts, I kindof glossed over the different kinds of data types you might have in your application and when you might choose a specific type. I now seek to rectify that oversight, but first I need to talk about types in a more general sense:
Eric's Taxonomy of HealthVault data types...
With the exception of custom types, all types are defined by the HealthVault platform. Take a minute to look at the platform ThingType Reference (which is always the definitive reference to what data types are deployed on the HealthVault servers).
You probably already figured out that each of the classes derived from HealthRecordItem correspond to a "thing type" here - the AerobicSession class is a AerobicExerciseSession thing type on the server, the Appointment class is the Appointment thingtype. And you may also have figured out that if you click on the guid for the thingtype, you'll get a page that shows more information about that type.
If you spend a lot of time looking at that list, you may notice that there are certain thing types that don't have corresponding classes (Continuity of Care Record, for example). For those thing types, there is an XML schema underneath the type.
Sometimes that's because we haven't written a .NET wrapper around the thing yet (just adding a new thingtype is easier and quicker than creating/testing the wrapper), and sometimes it's because we've decided not to write a wrapper for the type at this time.
And then, of course, there are the custom types, so the overall taxonomy is:
Choosing the right option for your information
The right option for your information depends on the kind of information it is and how you expect to use it.
Initially, it will probably be simplest to develop new types as custom types - that way you understand what should be in them, how they fit into your application, etc.
Then, if the information would be widely useful to other applications (ie if we didn't have a Weight type and you wanted to store weight), that's a good indication that it belongs in the platform. At that point you should request a new type, which may involve some discussion between you and MS over the details, and, after a (undefined but hopefully fairly short) period of time, the new type will show up in the platform.
Conversely, if the information is very specific to what your app does, you may want to leave it as a custom type.
That's for types that are very different. If you have a type that is close but not quite the same as a type we already have, you may want to extend the type yourself (using CommonData.Extensions), or you may want to request a modification of an existing type (which may or may not be feasible, depending on the type and what you want to do to it).
If you have questions about what to do with a specific bit of data, please ask on the forums.