locked
Is it possible to update a HealthRecordItem using XML navigator RRS feed

  • Question

  • Hi, everyone,

    Currently I am looking for a general approach to handle all data types in HealthVault, XML is the first thing to pop up in my head, I know there is a way to insert an item using xml navigator, something like the following code snippet.

    HealthRecordItem item = new HealthRecordItem(Height.TypeId, @"<height>...</height");
    HealthRecordAccessor.NewItem(item);

    I am using the Height as an example, of course, the xml string is not correct, but just to show the idea.

    But could anyone tell me how I could do the same thing to update the item? In order to update an item, I need to get the HealthRecordItem first, of course I could get the xml string and manipulate, but I don't know how to write back to the HealthRecordItem. Any idea?

    Thanks,

    Kane Wang
    Senior Application Developer
    Guide Productions

    Wednesday, May 27, 2009 10:15 PM

Answers

  • To your specific question-- if you can put together the right XML for a PutThings request, you can write back to the item... you just have to make sure your XML output matches the PutThings schema and the data type schema inside the call.  Getting the XML into that format is up to your application and XML manipulation logic.

    With regards to the overall topic in your first sentence about a general approach... in theory, you could try and approach the HealthVault data types as one giant monolithic XML block, but I don't recommend it.  The design intent on our end is that each Thing Type has a XML schema, and each web service call has an XML schema.  Those are the atomic levels of XML in the system; you could combine all that together and treat it as one giant nested XML and then use XML libraries (like XmlNavigator or XPath, etc) to do operations on top... that's up to you.

    Part of the problem of trying to develop a general approach here is that you're trying to generalize specific, atomic, and largely independent data types.  Yes, they all have some common sections (like audit history, etc), but that's already exposed via the underlying base.xsd and date.xsd schemas that the other schemas reference.  After those common elements, in order to do interesting things with most of the data types you need to understand what the data type is representing and how that data should be used, which requires more specific and less general logic.  LabTestResults have to be handled in one way versus Conditions, for example... different vocabularies are used, different user interfaces are more appropriate, etc.

    Anyhow... there are some general ways to approach things.  One app that does a great job of generalized data viewing and editing is the Developer's X-Ray tool from GetReal Consulting:  https://xray.getrealconsulting.com/ 

    Check it out for an idea of how you may be able to treat data types in a generalized way.

    However, the specifics of how to do so are largely something you'll need to determine yourself, as the vast majority of applications are better served by specific, and not general, approaches.
    Monday, June 1, 2009 8:00 PM

All replies

  • To your specific question-- if you can put together the right XML for a PutThings request, you can write back to the item... you just have to make sure your XML output matches the PutThings schema and the data type schema inside the call.  Getting the XML into that format is up to your application and XML manipulation logic.

    With regards to the overall topic in your first sentence about a general approach... in theory, you could try and approach the HealthVault data types as one giant monolithic XML block, but I don't recommend it.  The design intent on our end is that each Thing Type has a XML schema, and each web service call has an XML schema.  Those are the atomic levels of XML in the system; you could combine all that together and treat it as one giant nested XML and then use XML libraries (like XmlNavigator or XPath, etc) to do operations on top... that's up to you.

    Part of the problem of trying to develop a general approach here is that you're trying to generalize specific, atomic, and largely independent data types.  Yes, they all have some common sections (like audit history, etc), but that's already exposed via the underlying base.xsd and date.xsd schemas that the other schemas reference.  After those common elements, in order to do interesting things with most of the data types you need to understand what the data type is representing and how that data should be used, which requires more specific and less general logic.  LabTestResults have to be handled in one way versus Conditions, for example... different vocabularies are used, different user interfaces are more appropriate, etc.

    Anyhow... there are some general ways to approach things.  One app that does a great job of generalized data viewing and editing is the Developer's X-Ray tool from GetReal Consulting:  https://xray.getrealconsulting.com/ 

    Check it out for an idea of how you may be able to treat data types in a generalized way.

    However, the specifics of how to do so are largely something you'll need to determine yourself, as the vast majority of applications are better served by specific, and not general, approaches.
    Monday, June 1, 2009 8:00 PM
  • Thanks for the decent reply.

    Kane
    Monday, June 1, 2009 9:44 PM