locked
Provisioning? RRS feed

  • Question

  • I'm trying to figure out if it's possible to control account/record "provisioning" from within my application.  From what I can tell, there are a number of key steps to complete:

    1) log-in with a Live ID or create a new Live ID
    2) create a HealthVault account and record
    3) create 1 or more additional HealthVault record(s)
    4) give consent for appropriate Application permissions

    I realize that I can do all of this directly from the HealthVault site, but the Developer's Guide (page 51) also indicates that some of this administrative functionality is available programmatically via Bobcat URLs.

    If I'm reading the documentation correctly, everything but step 2 can be accomplished by calling a URL with the correct query string parameters.  In step 2, it seems I can load the URL/page with a redirect back to my own page, which would provide a slightly more integrated (though not perfect) user experience.  Am I correct here?

    Secondary questions:

    I'm wondering why CreatePersonAccount is only available interactively?

    Any consideration to adding a RemovePersonAccount.aspx and RemoveRecord.aspx to complete the end-to-end scenario?

    Does the schema for authXML, used by AuthorizeRecord.aspx, allow me to change/remove permissions in addition to setting them up?

    Clearly my goal here is to provide the optimal, integrated user experience.  Obviously the user can go to the HealthVault site at any time and manage their records & permissions there - not trying to prevent that at all (not that I could even if I wanted to).  I just want to make the experience as seamless as possible for the primary setup and management use cases.

    Any additional thoughts on this topic?  Thanks!!

    - Mark O


    Monday, October 22, 2007 8:20 PM

Answers

  • Mark,

     

    I understand your desire to provide a seamless experience.

     

    There's a tension between that and our desire to make sure that users can clearly understand what data is being stored on HealthVault and who is able to access that data. To do that well, it has to be as simple and straightforward as possible, and having that done through a central location that users know and understand is better than having it be done in a lot of different applications.

     

    I guess that's a long way of saying that we're very likely to continue to require that provisioning, login, and authorization remain on the HealthVault pages.

     

    Hope that makes sense.

     

    Monday, October 22, 2007 9:00 PM

All replies

  • Mark,

     

    I understand your desire to provide a seamless experience.

     

    There's a tension between that and our desire to make sure that users can clearly understand what data is being stored on HealthVault and who is able to access that data. To do that well, it has to be as simple and straightforward as possible, and having that done through a central location that users know and understand is better than having it be done in a lot of different applications.

     

    I guess that's a long way of saying that we're very likely to continue to require that provisioning, login, and authorization remain on the HealthVault pages.

     

    Hope that makes sense.

     

    Monday, October 22, 2007 9:00 PM
  • Thanks Eric, it makes sense.

    I completely "get it" in terms of the balance and trade-off between user experience and providing a clearly separate and simple administrative interface.  There are several different perspectives on this (which I won't go into), but I appreciate the direction you've taken.

    The primary reason I raised these questions was because the SDK documentation lead me to believe that some/most of the administrative interface was already available "programmatically", or could be integrated a little more seamlessly at some level .  Sounds like this is not the case, and not the direction.

    - Mark O


    Monday, October 22, 2007 9:59 PM