locked
Integrating Apps into HealthVault RRS feed

  • Question

  • I was wondering if any thought has been given to actually integrating the applications built for the HealthVault ino the Vault at HealthVault.com. That is not having the visitor have to navigate away from the web site to have to input his data into a third party web site only have to navigate back later to find his data in the Vault. This is entirley very confusing for the average person. Actually, I have met thers who actually thought there was nothing to the Vault except uploading some files beause they completely glossed over the way programs worked and how you have to link them to your Vault. It would be much easier if the app was integrated and I would not have to navigate away from the web page. This is a very key issue from a usibilty stand point. I would highly encourage the Vault developers to give this some thought as this is not just coming from one source. I am a health are providers and a web developer and would love to tell my patients about the vault however i have found many of them not to be technicaly savy enough to use the web site. if it was easier to use it would be much more useful.

    If you dont want to integrate the apps, in the least provie the basic set of functions in the acual HealthVault like inputing medications, disease, prceudres, etc.

    thanks
    Tashfeen

    Wednesday, October 17, 2007 7:28 PM

Answers

  • When a type request comes in, we will look at it to see how it fits into our approach to types. Some types may be modified/generalized before they are implemented.

     

    If somebody else needs something different from that type in the future, it is possible to extend types (at least in some situations) while being backwards compatible.

     

    All of this is owned by the part of the HealthVault team that owns type definition and implementation.

     

    Does that answer your question?

     

    Friday, December 7, 2007 5:35 PM

All replies

  • The web site at https://account.healthvault.com is intended primarily for account management, not as an end user application.  We see most end-users entering the system from applications that third-parties write, not through www.healthvault.com.  Over time we may write our own applications like a PHR but we don't know if or when that might be.

     

    A corrolary would be the account management page for a Windows Live ID (Passport). Most people don't even realize the web site to manage their Live ID exists, they generally only see the signup and login pages.  They enter into the Live ID pages through an application that they sign up for and redirect back to the application after sign up is complete.  They never really interact with the entire site provided by the Live ID service.

     

    Jeff Jones

     

    Wednesday, October 17, 2007 9:57 PM
  • Thanks for your reply. Is there an way to make the process more transparent to the users? From a usability standpoint, it is very confusing. The concept of using a third party application that is housed at the thrid party web site is a confusing concept to the every day man. I am interested in developing an application but am trying to get an idea of how much time to put in to it. I have a feeling many users might be turned away from the HealthVault because of this confusing concept. Something like Facebook platform would work well because it allows third parties to develop and have the application directly integrated.

     

    Thanks

    Tashfeen

     

     

    Thursday, October 18, 2007 3:09 PM
  • Thanks for your thoughts Tashfeen.  We have designed HealthVault to be a platform that partners can leverage along with their own domain expertise, to provide unique services to their customers.  HealthVault is not meant to be a destination point in which partners can embed their user experiences directly, although this doesn’t preclude us from offering an experience of that sort in the future.

     

    I wanted to call out for you, benefits that HealthVault currently offers to its partners (i.e. people & organizations that build on top of our platform):

    • Private and Secure Storage -- We want to make it easy to for people to collect health information from a variety of sources (of their choosing, and avoiding manual data entry as much as possible), store it, and selectively share it.
    • Secure Sharing -- HealthVault enables users to easily & securely share their health information with family members, caregivers, healthcare providers, and partner applications and services.
    • Device Connectivity -- By integrating with HealthVault, a partner application can easily request access to information uploaded from a wide range of HealthVault-compatible devices.
    • Application Interoperability -- Similar to data coming from devices, relevant personal health information generated or collected by other HealthVault partners can be made available to your application and vice versa (with user consent, of course).  Thus, there is a much lower bar for users to sign up for a HealthVault partner application, because they know that they can re-use any existing data they have, and that any data they put in the application will be re-usable by other partner applications.
    • Authentication -- Partners can secure their pages using HealthVault authentication which leverages Live ID.
    • Discovery -- Via www.HealthVault.com, and sponsored results in HealthVault Search (see https://health.live.com/results.aspx?qu=exercise for an example) partners can attract highly motivated users.  Through the advantages described above, customer loyalty and retention will increase.

    thanks,

    Kalpita

    Saturday, October 20, 2007 12:56 AM
  • Kalpita, if I'm understanding you properly, I can certainly see where Tashfeen is coming from.  It sounds like HealthVault is simply a value-added datastore but really doesn't help customers reduce the complexity of managing their healthcare information. 

     

    If developers use HV to store their user’s data but can’t enable them to reason about that data when accessed directly from the Vault, customers will always have to access their data directly from third-party apps.  That means users will not only have to access their data through numerous distinct applications but you’re also not likely to get any existing applications to tie into the vault. 

     

    Consider an existing HIM system that wanted to utilize HV to enable patients to access their medical records.  If that system’s developers, and presumably others, could embed their application within HV, it would appear to end users that they’ve got a single source of healthcare information and the cost for dev teams would be significantly lower than if they had to build an entire data access website on their own.  And if they have to do that, why wouldn’t they just use their existing data store? 

     

    Of course there’s also the fact that if HV is the center of the user experience, Microsoft will generate far more ad revenue.  The motivation, I presume, behind this entire initiative.

     

    I don’t think all applications should be tightly coupled with the vault, but it appears being able to offer developers the ability to embed their application within it could be a major boon for users, partners, and Microsoft.

     

    Let me know if I’m missing something.

    Sunday, October 21, 2007 11:54 PM
  • I would just like to echo what Breeze Medical said. I think taking the helathvault which is not a end user porduct and turning it into one will be essential in securing further developers to develop and further integration. The platform built and the intent behind is great however it does not seem to solve the complexity of the helath system of having to go to many sources for health care info and input. As a developer, having the ability to embed my application is a much more attractive option. It ensures that my users are not confused by having to navigate away. In addition, many have faith Microsoft and when forced to navigate away they might not trust me the small player software maker in the whole scheme of things.

    Also, technically speaking, labeling the HealthVault as not an end-user application is not accurate as there is some inherent function in it like uploading files. If it truly were just a platform one would have to remove even that and allow that to be built on top by someone else...
    Monday, October 22, 2007 1:51 AM
  • Also, when I asked about integrating, i did not intend that Micorsoft would have to acutally house the appliation. The application would still be housed by the thir party it woud just give the imporession to the users that it is one unified experience. ie the applicatin would be seen on a iFrame keeping it independent fro the rest of the HealthVault.

    Thanks

    Monday, October 22, 2007 4:41 PM
  • I think I understand what you're saying (though I'm not exactly clear on what you mean by "embed"). And I'm not really trying to convince you, since our goal is to be driven by a vision we share with partners.

     

    So, see if this makes sense.

     

    One of our fundamental tenets is that access and analysis needs to happen in a way that works for whoever needs to access the data. If a patient is managing their blood pressure, they may want a very simple app to view their data, while their physician will want to view that data integrated with all the other patient's information. I don't think you can tell the physician to go to a website to look at a patients data because that just makes their life harder.

     

    It's also true that we are not subject matter experts in the health and fitness area. Rather than trying to limit partners to something that fits into our idea of interface, partners have the ability to create something that works well for their target audience. That gives the partner far more flexibility and agility.

     

    For existing applications, I see a few big benefits.

     

    First of all, you get built-in device support - you don't have to build any of that. Second, you get data sharing across multiple applications in ways you just can't get now.

     

    If you have high blood pressure, you are likely measuring your blood pressure on an ongoing basis and on an exercise program. But in most cases, that data doesn't get shared directly, and physicians only find out during visits the rough outlines of what their patient is doing by asking them. But if they are hooked together through a central store like HealthVault, the physician can see the daily BP readings for the past month and note that they are exercising 45 minutes a day nearly every day. I think that will result in more productive interactions between patient and physician.

    Monday, October 22, 2007 11:10 PM
  • Thanks for the reply Eric, this is a great thread.

     

    Regarding your points on making data accessible through the mechanisms users are familiar with (e.g. doctors not having to use HV to view their patient’s data), subject matter expertise (e.g. MS doesn’t have any and doesn’t want to), and device integration being beneficial, I whole heartedly agree.  In fact, I don’t think you should change a thing here.  Partners need to be able to make their data accessible outside of HV if they want to and they should be able to define exactly how their users reason about their application’s data.

    What I disagree with is that the above is the best model from a user and partner perspective.  I would argue that if developers got to choose between presenting their users’ data independently of HV or embedding it within it, everyone will be better off.

    (Note: when I refer to “embedding” the data presentation within HV, think of Windows Live gadgets or Sharepoint web parts.  In other words, imagine HV as the primary portal where users access/manage their healthcare information via partner-developed portlets.)

    Let's take the example you outlined – a patient wants to track her blood pressure along with her diet and exercise routines through different HV-enabled apps.  First off, with the HV “portal model”, when the user enters new data, presumably something she’ll have to do every day, she doesn’t have to go to multiple websites.  If everything is accessible directly from the HV, she could conceivably enter all the data necessary on one web page using multiple HV portlets. 

    Secondly, when she wants to share out who can access that data (e.g. her doctor), she’s already in the vault and with a few more clicks, it’s available for access.  Now if her doctor wants to see all this data and the “portal model” isn't available, he/she would have to log into multiple web apps - a major pain.  Let me know if I’m missing something here, otherwise, I think you see where I’m going.

    There are also distinct advantages for developers, not to mention a terrific ad-based revenue stream for Microsoft, with the portal model but this post is getting long enough as it is. 

    Let me know what you think; providing partners the choice between independently presenting their application’s data outside of HV or embedding it within the value seems like a win-win for everyone.

    Tuesday, October 23, 2007 6:57 AM
  • Thanks - I understand better what you are proposing. It's an interesting idea, though I think that there's a considerable amount of complexity in doing so, and I don't know how it would fit into our current business model ideas (I'm not the business model guy).

     

    It's something we'll consider for the future...

     

     

    Tuesday, October 23, 2007 3:16 PM
  • Great, sounds like we're on the same page Eric.  Tashfeen, would a portal model meet your needs as well?

    Wednesday, October 24, 2007 4:59 AM
  • Yes, a portal model would meet my needs. Actually, that is exactly what i was proposing but obviously Breeze is much better at expressing it than I am. Smile

    Here is a slight vrioation to what was proposed above. Perhps, it could be both and the way the application is visualized is based on how you get there. So, if I am logged in the HV then I open an application then it comes in the embeded form or the portal model. However, if it is accessed form the third pary site, then it could open it up as an indepedent application. However, this could be confusing....

    I think the concept behind HV is great. As a health care provider, I am sick of the lack of standardization issue and how health care has been lagging in appropriate IT infrastructure despite it being one of the largest industries in this country. I believe we will not standardizatrion unless someone decides to put significant money forward as it seems MSFT has done. I also applaud the strategy MSFT has taken in doing this as a callaborative effort. MSFT has decided to stick to what they do best which is IT and leave health care to the experts. This creates for a much better solution. For this reason, I am really hoping this effort succeeds.

    However, its success hinges on it being a user friendly experience which at the moment it is not. I have talked to several people who have used it and all have returned to me confused. I think a one-stop-shop is much better than having to go to many websites. Right now, if i want to manage my blood glucose, pressure, and use CapMed, I have to go to three different websites. And form the user's perpective how does HV fit in to that? (I know the answer but I do not think the average user does). It  is way too confusing right now.

    Eric, could please convey our concerns to those whom it is most appropriate? I do not think this is a minor issue. I really think this should be looked into further.

    I think you will also get more developers interested as having the application in the portal model gives us more credibility.

    Thanks

    PS - Could you please add the capability for the time being of linking the HV to the third party application. For example, right now, if I use AHA pressure monitor, it shows on the HV that they have access to my information and that I am using their applicatin. However, there is no link on that page to my application on AHA. ie, on the HV page about AHA in my HV account (not on the parterns list page) there should be a link I can click on and it opens up my application on the AHA web site so that I can go directly to editing my stuff.

    Saturday, October 27, 2007 7:20 PM
  •  

    We've had some more discussions about this topic and certainly will have more in the future, so it is fair to say that people understand your concerns. I appreciate the time both of you put into describing the scenario - it's much easier for me (and for all of us) when we have something that comes directly from a customer.

     

    I've added a suggestion for adding the link that you requested. I *think* that we have the proper information to enable it, but I'm not sure.

    Monday, October 29, 2007 4:34 PM
  • Thanks very much for following up on this issue Eric and for discussing it with your team.  It's great to see you guys taking user input so seriously at this stage of the game.

     

    Tuesday, October 30, 2007 4:19 AM
  • I represent the small software developer who is trying to develop a new front-end product for the healthcare market with some ideas that have been piloted in a few places. What has led me to despair in the past is understanding where and how to start to interface with other medical systems. I am looking for an entry point that is going to guarantee that if I adopt it, I will have an instant marketplace because it will give me a competitive advantage to be able to state that my product can access heath data in a standard way, on a standard highway.

     

    This year, we are stepping up our efforts to deliver a tablet solution for the mobile clinical professional. This product is called Field Clinician. We are trying to decide whether or not to target large private practices, or home healthcare agencies (REALLY mobile clinicians).

     

    We realize that a standardized EMR would benefit everyone. A very large hurdle for us is the domination of corporations like Cerner, McKesson and MISYS, which refuse to open up their back-office systems to vendors like us. These players seek to dominate the market by casting fear on their clients that a "complete" system is best for their clients. They offer their own front ends and mobile solutions, and are not interested in opening their back-office systems or data repository schemas to us.

     

    These systems contain a mix of information that is structured in a proprietary way such as visit scheduling information, etc., and medical records which should be in a standard format and schema and open to consumption and contribution, but are not.

     

    Consider that I am building a system for a private practitioner. He and I and others, say, have come up with a great UI that cohesively displays EMR data, charts, etc. So, now I want to hook up to Healthvault and discover for a patient the data that is stored, and its structure (relational tables, XML, etc.). How do I do this? I am not a subject matter expert on ALL the data that could be stored there. In fact, the physicians I work with themselves may not be intimate with the latest MRI data, or the way one of your partner producer/contributor vendors have structured that data.

     

    Just how do you intend to solve the problem of my systems discovering the schema of multi-disciplinary data on Health Vault? Must I partner with the application vendors that sourced and contributed that data? Can the SDK allow me to discover the structure as well as the data? I think you should be requiring that vendors that contribute data submit an abstract document, or schema, or web service API that allows consumers of the data to discover what data is available and in what format this data is provided.

     

    You are on the right track in providing a "repository playground" we can all produce and consume from, but the specification of the rules of play are not clear to me. I am more than willing to provide a portal that pulls the data into one application so that end users don't have to deal with 10 applications, but just as I had to know McKesson's EMR schema, I have to know the contributing vendors' data schema you are allowing to store in HealthVault. Are you going to force the
    openness" issue via your partner agreements, so I as a consuming vendor aren't given the cold shoulder?

     

    Wednesday, December 5, 2007 9:00 PM
  • First, as a brief aside, it's usually better to create a new post for a new question rather than adding on to an existing one.

     

    Here's how I look at it.

     

    The whole HealthVault Vision is built around data being shared across different applications. The big benefit that you get with a HealthVault-based solution is that you get that sharing, and if you're not going to play in that ecosystem, I think it doesn't make a lot of sense to work with HealthVault.

     

    I'm not directly involved with a lot of our partners, but my sense is that the partners that we are working with "get it". To address the EMR space specifically, I think that there are a few EMR vendors amongst our launch partners (though, as I said, I'm not an expert in what our partners are doing).

     

    To address the schema/data types question, HealthVault has a single set of data types. That set of data types is based on what partners have requested to have in HealthVault, and we're adding to the set of types on an ongoing basis as partners request them, with the goal of keeping one coherent set of types.

     

    Does that answer your question?

    Wednesday, December 5, 2007 10:56 PM
  • Yes, it does.

     

    So, then I should review these types with my physician clients as these types are newly defined/updated by either requests from other partners, or as requests from me.

     

    Who is the arbritrator if my type conflicts with another vendor partner's type? What might be the forum for that?

     

    Thursday, December 6, 2007 1:03 AM
  • When a type request comes in, we will look at it to see how it fits into our approach to types. Some types may be modified/generalized before they are implemented.

     

    If somebody else needs something different from that type in the future, it is possible to extend types (at least in some situations) while being backwards compatible.

     

    All of this is owned by the part of the HealthVault team that owns type definition and implementation.

     

    Does that answer your question?

     

    Friday, December 7, 2007 5:35 PM