none
Is HealthVault the right solution to our needs? RRS feed

  • Question

  • Hello Everyone,

    My small team has started the process of creating our new EMR solution and, so far, it's going great.  As a company that's solidly committed to Microsoft technology, we're seriously wanting to better understand and utilize HealthVault in our application but aren't sure we fully understand its usefulness. So I thought I'd ask a few questions to make sure we're on the right path with HealthVault:

    1. If our application uses HealthVault, does that mean we store our information in the HealthVault cloud, where it is universally accessible, instead of on a local database?

    2. Once patient data is placed in HealthVault, can the physician access that data from anywhere, even if he doesn't have our application installed?

    3. If the answers to questions 1 and 2 or 'yes', does this mean HealthVault can totally supplant the need for a traditional db in the application?

    4. If I'm wrong about questions 1 and 2, can someone point me to a simple, high-level view of what exactly HealthVaults role in the application would be?

    Thank you! I appreciate the help in advance.

    Sincerely,
    Anthony Papillion
    OpenEMR HQ
    www.openemrhq.com
    CEO/Founder, OpenEMR HQ, Inc
    Thursday, July 16, 2009 3:37 AM

Answers

  • Raj's answers are all correct above.  I'm going to provide my own as well, to provide another perspective and breadth:

    1. If our application uses HealthVault, does that mean we store our information in the HealthVault cloud, where it is universally accessible, instead of on a local database?

    As Raj mentioned, you can be a "native" application, and only store data in HV as your primary store, or non-native, and have your primary store external to HV and then do one-way or two-day data operations between the two data stores.  I want to add a bit more on something at the end of your question-- your comment that it is "universally accessible".  It's universally accessible in the sense that it exists in a cloud database behind an internet web service.  I wouldn't normally say "universally accessible", however.  Data stored in HV is under primary control of the HealthVault user/patient, and is accessible by the user and any applications the user explicitly authorizes to access their data.  At any time, any authorized applications (or the user) can read/write to the HealthVault data store.  It isn't under primary control of any one application.

    2. Once patient data is placed in HealthVault, can the physician access that data from anywhere, even if he doesn't have our application installed?

    Basically, no.  If the physician has access to other applications that the HV user has authorized to access their HV record, then yes.  But, in general, if the physician primarily uses your application to access a user's HV data, then the physician will only have access via your application.  Only users have direct access to data in HealthVault, physicians must use an application that the user has authorized.

    3. If the answers to questions 1 and 2 or 'yes', does this mean HealthVault can totally supplant the need for a traditional db in the application?

    Yes, with a caveat.  You're describing HealthVault native applications, where the HV database is the primary data store.  Lots of these applications exist today.  The caveat is that the application must understand that the HV DB is under the full control of the HV user, and can be shared across multiple applications (explicitly authorized by the user).  If that kind of user-controled shared ecosystem is okay with your application, then a native app is the way to go.  It's great from a user standpoint, and a data sharing standpoint.  But, if you have business or legal requirements around preserving data or need to maintain primary control of your DB, native may not be the way to go.

    4. If I'm wrong about questions 1 and 2, can someone point me to a simple, high-level view of what exactly HealthVaults role in the application would be?

    Please ask more questions as you learn more-- check out the MSDN Dev Center: the Getting Started Guide, the How To Guides, download the .NET SDK and check out the Sample Applications.  Running sample apps is a great way to start to understand first-hand how this all fits together.
    Thursday, July 16, 2009 6:33 PM
    Moderator

All replies



  • 1.  A HealthVault application does store information of users in HealthVault cloud. But that does not mean that should be the only place you could or should store your user's Health data.  There are primarily 2 class of applications - native and non-native (technically they are just HealthVault enabled applications). Native applications only store health data in HealthVault and does not have private data store. Non-native applications have their own health data store and exchange that information with HealthVault using single or bi directional data exchange with HealthVault. 

    2.  Physicans access user's data using HealthVault applications (as against users sharing his/her record directly with the Physician).  So your data can be consumed by a physican even if he uses a different HealthVault application.   This data sharing capablity where the true power of HealthVault is. 

    3. It depends on what the capabities of your application is,  the data types and format it stores data etc.  But if you are building a new appliction from scratch, you can choose the data types to align with what HealthVault provides and end up storing all the Health data in HealthVault.   But there are HealthVault applications which does not have any local data store.

    Hope this helps


    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Thursday, July 16, 2009 5:56 AM
  • Hi Raj,

    Thank you for taking the time to answer my HealthVault questions.

    While it's very tempting to store all of the patient data in the cloud, it's probably wiser for use to do dual storage until we are sure we fully understand the complexities of HealthVault. It's good to see that the service does allow for such hybrid applications and, from what I'm reading, doesn't add much significan complexity above that of creating native applications.

    Again, thank you for the information. I have a feeling these forums are going to become my best friend very soon.

    Anthony Papillion
    OpenEMR HQ
    www.openemrhq.com
    Thursday, July 16, 2009 12:57 PM
  • We would expect that your application would have its own data store and sychronize that with HeathVault rather than use HealthVault as a data store.

    The data in HealthVault is under the control of the user, which means the user can edit and/or delete any item of data. My guess is that for an EMR you would need to control the data yourself.

    For #2, the answer is no - providers only access data through applications.
    Thursday, July 16, 2009 6:19 PM
  • Thank you Eric. So I guess the answer is that HealthVault is more of a Google Health competitor than a competitor to any EMR system If I understand correctly, in that case, our application should really only push data up to HealthVault and not really bring any down or, at least, not rely on anything brought down that doesn't jive with the local data store. Correct?

    Thank You1
    Anthony

    CEO/Founder, OpenEMR HQ, Inc
    Thursday, July 16, 2009 6:23 PM
  • Raj's answers are all correct above.  I'm going to provide my own as well, to provide another perspective and breadth:

    1. If our application uses HealthVault, does that mean we store our information in the HealthVault cloud, where it is universally accessible, instead of on a local database?

    As Raj mentioned, you can be a "native" application, and only store data in HV as your primary store, or non-native, and have your primary store external to HV and then do one-way or two-day data operations between the two data stores.  I want to add a bit more on something at the end of your question-- your comment that it is "universally accessible".  It's universally accessible in the sense that it exists in a cloud database behind an internet web service.  I wouldn't normally say "universally accessible", however.  Data stored in HV is under primary control of the HealthVault user/patient, and is accessible by the user and any applications the user explicitly authorizes to access their data.  At any time, any authorized applications (or the user) can read/write to the HealthVault data store.  It isn't under primary control of any one application.

    2. Once patient data is placed in HealthVault, can the physician access that data from anywhere, even if he doesn't have our application installed?

    Basically, no.  If the physician has access to other applications that the HV user has authorized to access their HV record, then yes.  But, in general, if the physician primarily uses your application to access a user's HV data, then the physician will only have access via your application.  Only users have direct access to data in HealthVault, physicians must use an application that the user has authorized.

    3. If the answers to questions 1 and 2 or 'yes', does this mean HealthVault can totally supplant the need for a traditional db in the application?

    Yes, with a caveat.  You're describing HealthVault native applications, where the HV database is the primary data store.  Lots of these applications exist today.  The caveat is that the application must understand that the HV DB is under the full control of the HV user, and can be shared across multiple applications (explicitly authorized by the user).  If that kind of user-controled shared ecosystem is okay with your application, then a native app is the way to go.  It's great from a user standpoint, and a data sharing standpoint.  But, if you have business or legal requirements around preserving data or need to maintain primary control of your DB, native may not be the way to go.

    4. If I'm wrong about questions 1 and 2, can someone point me to a simple, high-level view of what exactly HealthVaults role in the application would be?

    Please ask more questions as you learn more-- check out the MSDN Dev Center: the Getting Started Guide, the How To Guides, download the .NET SDK and check out the Sample Applications.  Running sample apps is a great way to start to understand first-hand how this all fits together.
    Thursday, July 16, 2009 6:33 PM
    Moderator