This is the offical team web log for the Microsoft Customer Service and Support (CSS) Health Solutions Group. Posts are provided by Engineers within this team. Focusing on HealthVault, Amalga, IAM and other technologies...
I was working on a customer case, where they wanted to be able to enter demographic information (name, address, etc…) within their application and then redirect to HealthVault to create the account and not have to re-enter that information. They were already aware of the information that we had available.
HealthVault 1105 Release (see "Application initiated sign up and record creation") http://blogs.msdn.com/b/healthvault/archive/2011/05/24/healthvault-1105-release.aspx HealthVault Shell Redirect Interfaces (see "CREATEACCOUNT" and "CREATERECORD") http://msdn.microsoft.com/en-us/healthvault/cc265056.aspx
HealthVault 1105 Release (see "Application initiated sign up and record creation") http://blogs.msdn.com/b/healthvault/archive/2011/05/24/healthvault-1105-release.aspx
HealthVault Shell Redirect Interfaces (see "CREATEACCOUNT" and "CREATERECORD") http://msdn.microsoft.com/en-us/healthvault/cc265056.aspx
The 1105 blog post mentioned the following “Applications can send user information in POST data.”. However, I couldn’t find any documentation that outlined a list of what fields were available to send and what the names should be.
So, I decided to see if I could set this up. A collogue of mine sent me two aspx pages that were already made to get this going. I took those and slapped them into my Weight Tracker sample app to see if this would just work. I’ll go through both. Of note, my application is in the PPE environment and not in Production. The URLs reflect that.
The first piece of this is the Form tag on the page. This controls what will happen when we actually invoke the POST on the page (via the submit button).
<form id="AppInitCreateAccountForm" name="AppInitCreateAccountForm" method="post" action="https://account.healthvault-ppe.com/redirect.aspx ?target=CREATEACCOUNT&targetqs=<%= HttpUtility.UrlEncode(String.Format( "appid={0}", "<Your App ID Here>")) %>">
You can see that this is going to the redirect.aspx on the actual HealthVault page with a Target of CREATEACCOUNT. The only other item I’m passing in the query string is the Application ID for my app.
The page that I’m using has a bunch of fields on it to collect account information and patient information. The Patient information will be used to create the record within HealthVault and it doesn’t have to be for me. In this example, it will be creating my fictitious Son called Jim Doe, as I am the infamous John Doe!
When I hit my page and I click on the submit button, it redirects me to the link within the Action attribute of my Form Tag. This requires me to login to Windows Live as we are hitting HealthVault at this point. This account has never hit HealthVault before, so it makes sense that we are using the CREATEACCOUNT target.
After I login, I am then asked to create my HealthVault Account.
One thing to note here, is that it is already displaying some information that was entered on my form page within my own application. After hitting Accept, I then need to provide access to the Application itself.
After that is done, I get redirected to my application. I did not have to enter any information about myself or the patient (either myself or someone else).
If I go back into HealthVault, I can see that everything was entered successfully.
CREATERECORD is used if the end user already has a HealthVault Account, but wants to add another Record to that account. The form that I have is more simplified than the Account page, as I don’t need the info for the Account. When I hit the submit button, I get the following:
Note: If you are not logged in, it will first prompt you to log in.
After I hit Create Record, I grant my application access to the Record.
Again, I am not prompted to provide any demographic information because it was entered in on my Application’s page and I passed it to HealthVault.
The one thing that I did not see mentioned in the documentation was what fields were available. So, here are the fields that I know about for your reference. This is as of build 1105. There are the fields that I had in my sample page.
Account_FirstName
Account.FirstName
Account_LastName
Account.LastName
Account_BirthDate
Account.BirthDate
Account_StateCode
Account.StateCode
Two Letter Code
Account_PostalCode
Account.PostalCode
Account_CountryCode
Account.CountryCode
Account_Email
Account.Email
Account_Gender
Account.Gender
f, m or u - u is for I'd rather not say.
Account_LanguageCode
Account.LanguageCode
Record_Relationship
Record.Relationship
1 (Self), 2 (Other), 3 (Spouse), 5 (Child), 6 (Guardian), 7 (Patient), 8 (Parent), 10 (Relative), 11 (Domestic Partner), 13 (Pet), 14 (Son)
Record_FirstName
Record.FirstName
Record_MiddleName
Record.MiddleName
Record_LastName
Record.LastName
Record_StreetAddress1
Record.StreetAddress1
Record_City
Record.City
Record_State
Record.StateCode
Record_PostalCode
Record.PostalCode
Record_CountryCode
Record.CountryCode
Record_PhoneNumber
Record.PhoneNumber
Record_BirthDate
Record.BirthDate
Record_Gender
Record.Gender
Record_LanguageCode
Record.LanguageCode
Record_Ethnicity
Record.EthnicityCode
1 (American Indian or Alaska Native), 2 (Asian), 3 (Black or African American), 4 (Hispanic or Latino), 5 (Native Hawaiian or other Pacific Islander), 6 (White), 7 (Mixed Race), 8 (Other Race)
Based on a recent forum post, we came across that there is a hidden field that needs to be present for this to work. There are separate ones for the Account/Record creation and just the record creation.
<input type="hidden" id="CreateAccountAndRecord" name="CreateAccountAndRecord" value="True" />
<input type="hidden" id="CreateRecord" name="CreateRecord" value="True" />
You would just need to add the one that is relevant to what you are trying to do. At this time, these fields are not documented within the SDK documentation. This should be corrected in the future. Without those fields, it will just pull account information from your Live ID login and will not pass over the record information.
Adam W. Saxton | Microsoft HSG Escalation Services http://twitter.com/awsaxton
Thanks, the post helped me a lot.
Is it possible to provide the recipient email address in the SHARERECORD target in a similar way?