locked
Filter records by ApplicationID RRS feed

  • Question

  • Hi,

     

     In my application I have a scenario where I want to get get all the records in HealthVault that have NOT been created by my application.

     

    In the search filter, I see that there is a CreatedApplicationID filter. What I am trying to do here is to say where CreatedApplicationID != MyAppID, how can I achieve this?

     

    I tried looking into using XPath but I can't find the "path" to supply to the query.


    Thanks,

    Burag

    Tuesday, February 12, 2008 6:19 PM

Answers

  • hi Burag -

     

    We dont support xpath query for created-app-id. Everything only under /thing/data-xml/ can be queried using xpath. Also in the GetThings request schema we dont support != operator on created-app-id.

     

    One way you can achieve this is by retrieving all records and then filtering it on your side. Just curious, what kind of functionality you are trying to build with this? Also, this seems interesting feature and we are inclined to add this to our partner requested features.

     

    Hope this helps.

     

    regards,

    Vaibhav

     

     

    Tuesday, February 12, 2008 10:50 PM
  • Burag,

     

    Thanks for the explanation. I think I understand enough about what you are doing to give you some guidance.

     

    Creating an architecture where data lives both inside and outside of HealthVault has a fair amount of complication to it. To do it well, you need to be able to track how your record relates to the records in HealthVault. You can do this by storing the unique identifier (item.Key.Id) and the version stamp (item.Key.VersionStamp).

     

    The sync then works roughly as follows:

     

    1) Any item that is in the list of HealthVault items but is not in your list (ie you haven't recorded the item.Key.Id) is a new item to your application.

     

    2) Any item that is in the list of HealthVault items but is in your list, but has a different item.Key.VersionStamp is an updated item, and the version in your app should be updated.

     

    3) Any item in your list that isn't in HealthVault is added to HealthVault

     

    4) Any item that's updated on your side is updated in HealthVault

     

    There are some subtleties in there, but that's the basic idea.

     

    As an aside, it's not acceptable for an application to overwrite a record that the user or other applications have updated.

     

    I hope that helps - let me know if any of it isn't clear.

    Tuesday, March 4, 2008 10:16 PM
  •  

    A couple of thoughts.

     

    First, if you come across an updated version of a record that does not have the information you originally put in it (or suspect that you originally put in it), you can always get to the older version through the audit trail. Using that and trying to create an updated version that is correct would be preferable to merely updating on top of the existing version, though there are cases where that wouldn't be possible or practical.

     

    Second, I think the number of cases in which you update an existing record should really be pretty minimal - in the vast majority of cases I'd expect that a new record would be written rather than updating an existing one. If you have a scenario in mind where you think you have to do an update, I'd be interested in understanding it.

     

    Finally, I agree with you that there is difficulty in having types that are transferable across platforms, and there are some situations where it's pretty hard to do the right thing. I think that apps should do their best, however, to preserve the existing data as well as possible. In the codable value sense, if you can determine what a value is by interpreting the codable value, then you shouldn't modify the healthvault data just to make it simpler for your app to parse the next time.

     

    Finally further, if you have specific where you don't see a good alignment between the data types you have and the types in HealthVault, let us know, and we'll work with you to see if there are modifications to the data type to make it work better.

     

    Hope that helps.

     

     

    Wednesday, March 5, 2008 9:42 PM

All replies

  • hi Burag -

     

    We dont support xpath query for created-app-id. Everything only under /thing/data-xml/ can be queried using xpath. Also in the GetThings request schema we dont support != operator on created-app-id.

     

    One way you can achieve this is by retrieving all records and then filtering it on your side. Just curious, what kind of functionality you are trying to build with this? Also, this seems interesting feature and we are inclined to add this to our partner requested features.

     

    Hope this helps.

     

    regards,

    Vaibhav

     

     

    Tuesday, February 12, 2008 10:50 PM
  • Hi Vaibhav,

     

     I was inclined to do the same already. It looks like filtering on the client side (my application) will be the solution to this problem.

     

    The idea is simple. We want to push "read-only" data to Health Vault. Such that if another Health Vault facing application changes the record we don't want to reflect the change on the original in the system (at the same time we want to work on data that is put in the Health Vault by other partners).

     

    Idea was to get only records that have a created application ID != myAppID. It looks like same behavior is achieved by getting all parts of the record and then working with the item.LastUpdated information to filter out the unwanted records.

     

    Obviously this has some performance impact on our end but nonetheless it should work fine. Thanks for your help.

     

    Regards,

    -Burag

     

    Tuesday, February 12, 2008 11:16 PM
  • I just want to make sure that I understand your scenario so that we can add functionality if needed...

    I am going to restate what you said. Please let me know where I'm right and where I'm wrong.

     

    You are creating some HealthRecordItems in HealthVault for a user.  You don't want to update these instances from your application once they have been written, but you do want to be able to update instances created by other applications. Does that sound correct?

     

    What about items that you created but have since been updated by another application?

     

    Thanks

    Jeff Jones

     

    Tuesday, February 12, 2008 11:51 PM
  • Jeff,

     This is what the app is currently capable of:
     1) Export records to Health Vault from the app and later update/delete them explicitly.
     2) When searching for records in Health Vault, have the ability to say where ApplicationID != myOwnApplicationID, such that I don't get a copy of records I already know about.

     I am achieving this 2nd behavior by pulling everything with the Audit information and then querying all items that have an ApplicationID != myOwnApplicationID. Obviously this is much more costly and less effective. If I could specify this in my query to begin with and do the filtering on the HV servers, this would be extremely convenient.

    I hope above explanation helps.

    Thanks,
    Burag

    Wednesday, February 27, 2008 5:08 AM
  • Do you need to differentiate between items that your app created and haven't been touched vs. items that app create and have been updated by a different app?

     

    Jeff Jones

     

    Wednesday, February 27, 2008 4:44 PM
  • I would care about the "creator" of the record, not the last touched application.

    This is the reasoning behind it, if I am the owner of the record, I always have the most "correct" data, and in collision situations I will overwrite the record in Health Vault with my own updated version, therefore I would only want to filter by CreatedApplicationID != myOwnAppID

    Thanks,
    Burag

    Wednesday, February 27, 2008 6:49 PM
  • Burag,

     

    Can you explain your scenario a bit more? What sort of "read-only" data are you speaking of, and why would an updated value from another application not be of interest to your application?

     

    Thursday, February 28, 2008 5:02 PM
  • Eric,

     What I am trying to achieve is to build a "local buffer" of items within the boundaries of the client (my) application for further processing. Displaying the data "on the fly", by requesting it from Health Vault each time is not feasible for our purposes.

    Instead, the user initiates a "synchronization process" with Health Vault such that the records are imported/exported. Imported in this scenario means that records in Health Vault are  mapped to our internal representation after being filtered, and discarded if they don't meet the criteria. After this step, we further process the data through other services that we consume in the application.  This is why the data is "read-only". Health Vault data is being fed into other services as input, but the original copy does NOT get edited through the client (my) application.

    As per the export part of the scenario, the service described above takes a copy of user created records (not originated from HV) as well. If these records get edited while in Health Vault, and become "unusable" by the application we'd need to "restore the original". Because of the complexity of this issue, we have decided to push out the data as "read-only" as far as the application is concerned. In other words, user can keep updating the data in Health Vault through the client application ONLY. Other applications can utilize the data (and even change it) but the application will overwrite the record next time user initiates a Synchronization process.

    Because of this, I do NOT want to get back my own exported records unless I do a specific ID search (which is what I do when I need to update items in Health Vault that I have previously exported).

    -Burag

    Monday, March 3, 2008 3:47 AM
  • Burag,

     

    Thanks for the explanation. I think I understand enough about what you are doing to give you some guidance.

     

    Creating an architecture where data lives both inside and outside of HealthVault has a fair amount of complication to it. To do it well, you need to be able to track how your record relates to the records in HealthVault. You can do this by storing the unique identifier (item.Key.Id) and the version stamp (item.Key.VersionStamp).

     

    The sync then works roughly as follows:

     

    1) Any item that is in the list of HealthVault items but is not in your list (ie you haven't recorded the item.Key.Id) is a new item to your application.

     

    2) Any item that is in the list of HealthVault items but is in your list, but has a different item.Key.VersionStamp is an updated item, and the version in your app should be updated.

     

    3) Any item in your list that isn't in HealthVault is added to HealthVault

     

    4) Any item that's updated on your side is updated in HealthVault

     

    There are some subtleties in there, but that's the basic idea.

     

    As an aside, it's not acceptable for an application to overwrite a record that the user or other applications have updated.

     

    I hope that helps - let me know if any of it isn't clear.

    Tuesday, March 4, 2008 10:16 PM
  • Eric,

     Thanks a lot for the information you have provided. I had a 100% similar design to yours. The only problem is that the updated items do create conflicts when there are updates to both versions between synchronizations.

    When these conflicts happen, we make it such that our application wins the conflict at any given time (otherwise we'd have a corrupt representation of data .e.g: User enters a medication dosage and route. Another application changes the route, if we use this new route and old dosage in our application we'll get a medically incosistent record). Also, there are cases where the data updated in Health Vault cannot be interpreted by our application. For example:

    In some cases our application is more strict in terms of the data it can interpret (int only whereas HealthVault can store a "CodableValue"), in such cases, we overwrite the data with the version that we can interpret. Otherwise, our own record coming back from Health Vault is not usable by our own application.

    So I guess, in scenarios where this happens very often, creating an extensions to the type to store our own "more strict" versions of the data would be more feasible. At the same time, if everyone goes with this approach we will end up with a very wide record that has the same information in many different fields under different representations.

    Frankly I don't know if there can be a silver bullet that will solve this problem all for once, considering there are many applications with many different representations of the same record types. Maybe if CCR standard gets implemented, we might be able to resolve this issue by talking the "same language".

    Thanks,
    Burag
    Wednesday, March 5, 2008 5:56 PM
  •  

    A couple of thoughts.

     

    First, if you come across an updated version of a record that does not have the information you originally put in it (or suspect that you originally put in it), you can always get to the older version through the audit trail. Using that and trying to create an updated version that is correct would be preferable to merely updating on top of the existing version, though there are cases where that wouldn't be possible or practical.

     

    Second, I think the number of cases in which you update an existing record should really be pretty minimal - in the vast majority of cases I'd expect that a new record would be written rather than updating an existing one. If you have a scenario in mind where you think you have to do an update, I'd be interested in understanding it.

     

    Finally, I agree with you that there is difficulty in having types that are transferable across platforms, and there are some situations where it's pretty hard to do the right thing. I think that apps should do their best, however, to preserve the existing data as well as possible. In the codable value sense, if you can determine what a value is by interpreting the codable value, then you shouldn't modify the healthvault data just to make it simpler for your app to parse the next time.

     

    Finally further, if you have specific where you don't see a good alignment between the data types you have and the types in HealthVault, let us know, and we'll work with you to see if there are modifications to the data type to make it work better.

     

    Hope that helps.

     

     

    Wednesday, March 5, 2008 9:42 PM