locked
Store patient and provider roles and links in HealthVault or local app database? RRS feed

  • Question

  • I'm working on an application that will allow patients and providers to communicate with one another and have access to a patient's blood glucose measurements (among other things). All users will be logging in using their HealthVault account for simplicity - we won't have our own login credentials.

    It sounds like the best way to acomplish this is to request offline access from users and then maintain our own record of who is a patient and who is a provider and which providers are authorized to view which patient's data. This way providers will be able to log in and see their patient's data even when the patient is not online.

    Obviously I need a way to identify which users are patients and which are not. My question is whether there is an appropriate place in HealthVault to store this and also the information linking a provider to a patient. I realize that this data might not affect how other applications restrict access to the data, but we are trying to store data in HealthVault whenever possible. Would it make more sense to just use a local database for this?
    Friday, July 31, 2009 11:49 PM

Answers

  • Regarding offline access—if users are using the HV login as the primary login, the app will be in an online context for those users by definition.  Offline isn’t necessary for user interaction.  That being said, for providers to pull data for patients while patients aren’t logged in, in that case offline is a good approach.  So offline is probably a good way to go for that—it’s just important that users log in via some secure mechanism before the offline connection is used.
     
    Regarding the patient/provider mappings: this sort of thing can in theory be stored inside HV or outside in your own DB.  Check the application-specific data types; apps can store user and app specific data in records.  Please keep in mind that any data stored in HealthVault may be modified by the user or other applications, so if you need to ensure your mappings are secure from modification it is best to store them in an external database.  In this case, I would likely recommend using your own DB in order to prevent users or applications from mapping providers to patients inappropriately.
     
    One other important thing to note is that providers should not be logging in with HealthVault accounts.  Providers should be accessing the application directly (which can use LiveID like HealthVault, but will be using LiveID outside of a HealthVault context).  Providers will not have a HealthVault record involved in this scenario, but will log in to the application, and then the application can retrieve and display HealthVault patient data using the offline credentials.
     
    In terms of identifying which users are members of which roles (patients, providers, etc), that’s up to the application, with the additional note that all providers should not be accessing other HV user data via a HealthVault account but should be using the HV-enabled application.  If HealthVault users fall into different roles in an application, it’s up to the application to determine those role mappings and identify users appropriately into those buckets.
    Saturday, August 1, 2009 8:27 AM

All replies

  • Hello Daniel Worthington,

    Following up with the team internally now-- should have an answer shortly.  


    Thanks
    Mahesh

    Saturday, August 1, 2009 1:47 AM
  • Regarding offline access—if users are using the HV login as the primary login, the app will be in an online context for those users by definition.  Offline isn’t necessary for user interaction.  That being said, for providers to pull data for patients while patients aren’t logged in, in that case offline is a good approach.  So offline is probably a good way to go for that—it’s just important that users log in via some secure mechanism before the offline connection is used.
     
    Regarding the patient/provider mappings: this sort of thing can in theory be stored inside HV or outside in your own DB.  Check the application-specific data types; apps can store user and app specific data in records.  Please keep in mind that any data stored in HealthVault may be modified by the user or other applications, so if you need to ensure your mappings are secure from modification it is best to store them in an external database.  In this case, I would likely recommend using your own DB in order to prevent users or applications from mapping providers to patients inappropriately.
     
    One other important thing to note is that providers should not be logging in with HealthVault accounts.  Providers should be accessing the application directly (which can use LiveID like HealthVault, but will be using LiveID outside of a HealthVault context).  Providers will not have a HealthVault record involved in this scenario, but will log in to the application, and then the application can retrieve and display HealthVault patient data using the offline credentials.
     
    In terms of identifying which users are members of which roles (patients, providers, etc), that’s up to the application, with the additional note that all providers should not be accessing other HV user data via a HealthVault account but should be using the HV-enabled application.  If HealthVault users fall into different roles in an application, it’s up to the application to determine those role mappings and identify users appropriately into those buckets.
    Saturday, August 1, 2009 8:27 AM