Alternate share invite email link

Question

Hello
I've been working on using HealthVault as a backend data store for patient data whereby the front end is a custom web interface, therefore I am making use of the Shell Redirect Interface. Currently I'm working on the scenario of initiating the share record
workflow using the SHARERECORD target. However I would like that the invite email that is sent redirects the user to my custom interface first rather than directly to HealthVault. The idea is that when the user arrives at my web application from the invite
link, my application would redirect to the shell interface where the user would continue as normal to create a HealthVault account and view the shared record.
Ideally I would like to provide a url to the SHARERECORD redirect which would be embedded in the invite email. Otherwise another option would be to allow my application to collect and provide the recipient information to the HealthVault SHARERECORD redirect
target.
Would either of these be possible? If not, what method would you recommend of achieving the same result?

Answer 1

Thanks for the reply Sean,
The Shell Redirect Interface allows me to retain the patient orientated nature of HealthVault, so I am not worried about that part.
I think I need to elaborate on the problem that I'm facing.
SCENARIO
When Tom goes to HealthVault and decides to share his record with Jane, Tom is presented with the HealthVault sharing screen where he will enter Jane's email address, an optional passcode, select which data types Jane will have access to etc. Currently when
Tom hits the 'Send Invitation' button, an email is triggered to Jane which contains a link to HealthVault to either accept or reject the invite. 
PROBLEM
The existing method (described above) would result in a HealthVault email being sent to Jane, which redirects her to HealthVault. However when the Shell Redirect (SHARERECORD target) returns to my application, it does not provide any details about to whom
the invite was sent to, therefore I cannot send my own email as suggested above (without prompting Tom to re-enter Jane's email address within my application, which wouldn't be a very good user experience).
POSSIBLE SOLUTIONS
It is at this point that one of the following would be an ideal solution:
The invitee's email address to be returned as the targetDetails when redirecting back to my application
Be able to provide a link which will be embedded in the email that HealthVault sends to the invitee as part of the SHARERECORD redirect target
Allow my application to collect some or all of the share information before providing it to the SHARERECORD redirect target
I hope this makes the issue clearer