HealthVault Production Server Maintenance - Thursday, November 12th

Update: Date changed to Thursday, Nov 12th.

On Nov 12^th we will be updating the keys used to create HealthVault credential tokens (which enable the “Keep me signed-in” feature).  Depending on the configuration of your application ID, and whether or not your application appropriately handles HealthVault Error Code 7 (translated by the .NET SDK to HealthServiceCredentialTokenExpiredException), your users may need to take action.

Your users may be impacted if your application relies on persistent user tokens – i.e. you have configured the “Automatic user sign-in duration” field in the Application Configuration Center (sample screenshot in Fig 1.).  If your application leverages the HealthVault .NET SDK, the SDK will automatically store a persistent cookie on the user’s machine with the expiry set to the number of seconds that you have configured.  If your application is not leveraging the .NET SDK, you have determined how you want to persist the token and are managing its expiry.

Fig1. Application Configuration for “Keep me signed-in” feature.

Once our keys have been updated on Nov 11^th, these user tokens will no longer be valid.  When users who have previously checked the “Keep me signed in” box (sample screenshot below, Fig 2.) interact with a feature in your application that requires them to be signed into HealthVault, their token will not be accepted by the HealthVault platform, and you’re application will receive an error from HealthVault.

Fig 2. HealthVault Sign-In process showing “Keep me signed-in” feature.

 

The impacted workflow is as follows:

1. A user who has previously checked the “Keep me signed in” box interacts with your application and initiates an action that requires them to be signed in to HealthVault.

2. Since a persistent token exists for the user, they will not be redirected to HealthVault to log in.  Whether your application uses the .NET SDK or not, the token will be presumed to be valid if it is not yet expired.

3. Your application will then attempt to use that token to make a request to HealthVault.

The result will be an error back from HealthVault – Error Code 7, or HealthServiceCredentialTokenExpiredException (.NET SDK).  Your application should be handling this situation by removing the cookie/deleting the token, and redirecting the user to HealthVault to sign in (sample for .NET). If your application is not appropriately handling this error, your users may receive an error from your application.  If your application is leveraging the .NET SDK, your guidance to them should be to delete their browser cookies, and we would recommend adding this to your Help files.

As an aside, if your users are using HealthVault Connection Center to upload data from a device, they will need to either sign out and sign back in, exit and restart the application, or restart their computer.  They will receive an upload error until they do so.

UPDATE: Added link to sample showing how to Handle HealthServiceCredentialTokenExpiredException.

Developer (PPE) Environment Data Cleanup – Thursday November 5th, 2009

On Thursday November 5^th 2009 we will be making an operational change to our HealthVault Developer (PPE) environment and cleaning up certain items that have data within their <other_data> element.

 

The following items may be removed during this effort: ExerciseSamples, GeneticSnpResults, File, PersonalImage, PasswordProtectedPackage, data uploaded from devices, and other items whose <other_data> elements have been used to store application specific information.

 

This event will cause no downtime, and the HealthVault Developer (PPE) environment will remain available.  However, you will need to recreate/re-upload any such data that you require for testing purposes.

 

We want to take this opportunity to remind you that HealthVault-PPE.com is a development and test environment only and it is not to be used to store personal information.

HealthVault 0908 Release Notes

HealthVault 0908 release is now available in the production and pre-production environments, with this release we are removing the beta label from HealthVault. UPDATE: Associated .NET SDK for this release is now available.

Below is the summary of changes in this release:

SODA (Software on Device Authentication)

SODA enables support for the creation of client and mobile HealthVault applications. Prior to SODA, this was – for the most part – not possible, because it would have required wide distribution of the private key your application uses to authenticate with the platform. SODA allows applications to create ‘instances’ of themselves. These instances are able to provision themselves with unique private keys and everything they need to authenticate with the HealthVault platform. The associated .NET SDK will be available shortly.

Full documentation on SODA is being written and will be posted as soon as it is available.

AllocatePackageID

This new API allows applications to request a DOPU package ID before sending the DOPU package. The DOPU package can then be sent later together with the allocated package ID. In discharge scenarios, for example, a patient does not have to wait until the package has been transferred to HealthVault before receiving the information necessary to later retrieve the package (package ID and passphrase).

CCR / CCD reconciliation improvements

• Reconcile UI: The UI has been completed overhauled and now consists of three pages – an introduction page, the reconcile page, and a summary page.
• The introduction pages explains the process and prepares the user. It also provides an option to simply add all the new data and bypass the remaining pages.
• The reconcile page has been redesigned based on extensive usability research. The page focuses on letting the user see and review the data before adding it to their HealthVault record.
• The user has the ability to choose not to add items, and to replace an existing item in their record with one from the file.
• The summary page shows the user all the items added from the CCR to their HealthVault record. If the user came from an application, the summary page provides a link to return to the user to that application.
• Duplicate Detection: The reconcile page now automatically detects items that are exact duplicates. If an exact duplicate exists in the HealthVault record, we will default the item to not be added to the HealthVault record. The user can override this and add it if desired.
• Billed vs. Diagnosed Conditions: The reconcile page now automatically detects Conditions that are possibly billed, and suggests that the user review the items before adding to their record. At this time, Conditions coded with anything other than SNOMED CT are flagged for review.

CCR Import / Export

• Data Mapping Improvements: The ‘tohv’ and ‘toccr’ transforms have been vastly improved. The transforms are now more robust and support the import and export of significantly more data elements to and from CCR.
• Improved Import Support: The ‘tohv’ transform is now imports the following into their appropriate HealthVault data types: Blood Pressure, Blood Glucose, Cholesterol Profile, Height, Weight. Prior to 0908 these were only imported to the generic vital-sign or lab-test-results data types.
• Improved Export Support: The ‘toccr’ transform now supports the following new data types: Payer, Directive, Condition, Family History, Allergy, Medication, Immunization, Height, Weight, Blood Pressure, Blood Glucose, Cholesterol Profile, Vital Signs, Lab Test Results, Procedure, Encounter
• Export to CCR: Users can now export their record to a CCR using the HealthVault Shell. This can be accessed by selecting “See all” in the record switcher, and then clicking the “Export record” link.
• Documentation: Documentation of the data mappings to and from CCR is being written and will be published to MSDN as soon as it is available.
• Compatibility: The changes to the ‘tohv’ and ‘toccr’ transforms were significant. If your application is using these transform and begins to encounter issues, the old transforms are still available from platform. The old transforms are available as ‘tohv_v1’ and ‘toccr_v1’. Please note that the old transforms are no longer supported, and are provided as a compatibility fallback only.

Please leave feedback in the comments.

HealthVault Server Migration

Sometime next week (the week of 8/17/2009), the HealthVault operations team will be moving our production servers to a new subnet.  If your corporate firewall has a special exception configured to allow communication with our servers then please contact hvSubnet@microsoft.com to get the new IP address range.  Please also let us know if you need more time to prepare for this change.

HealthVault 0906 Release Notes

HealthVault 0906 release is now available in the pre-production environments. Once it stabilizes in the PPE we will release it to production environment next week. The associated SDK is available for download now. Below is the summary of changes in this release:

HealthVault Platform Changes

Changes to the supported list of content encoding for blobs

This is described in detail here.

Configurable method set for Child applications

Master applications can now set a method ceiling for child applications. We required child application to have access to a fixed set of methods, with this change child applications can get all or subset of methods defined by the master application.

A master application can define the child method ceiling through Application Configuration Center’s “MasterAppAccess” tab. Child applications can be configured through the Add & Update application methods available to the Master application.

CCR / CCD Improvements

• Healthcare Providers contained in a CCD are now rendered in the CCD form transform and displayed when viewing the file in the HealthVault Shell.
• The CCR and CCD data types now have their own STT transforms.
• The CCR and CCD data grids have been improved based upon user research.
• The CCR form transform has been restyled to be more legible and have a consistent look and feel with the rest of the HealthVault Shell.
• Comments associated with items in a CCR are now displayed in the form transform.
• The Shell navigation will now be hidden from the user when they are using the RECONCILE target.  This change is meant to help funnel the user through the process and reduce the likelihood of them getting lost before returning to the application.
• The reconcile page will no longer reference the name of the standard, and instead reference the source of the file.  For example, what used to read “From Continuity of Care Record (CCR)” would now read “From Contoso Health Clinic…”
• Reconcile user terminology has been changed from “Integrating” to “Adding items”.
• The E-mail notification that gets sent if a CCR or CCD is uploaded offline has been rewritten for clarity and will include the source of the file to provide better context to the user.
• Users can now see all items they added from a CCR or CCD by using a “See added item” link from the CCR or CCD data grid.

New Redirect Targets

• We added a new APPREDIRECT Shell target.  This target enables an application in the HealthVault ecosystem to use the HealthVault Shell to redirect the user to another application’s action-url with a specified target and targetqs – eliminating the need to hard code URLs for app-to-app redirect.
• We added a new RECORDLIST Shell target.  This target lands the user on the record list in Shell.  This is a dead-end target and will not return the user to the application.

Shell User Interface Improvements

Changes in application authorization UI

We updated the application authorization user interface to make a number of usability improvements:

• The “select or add record” page now lists all the user’s records, not just those eligible to authorize the application, and explains why each can or can’t be selected at the moment. This is much better than hiding records (e.g., those already authorized) with no explanation. 
  
• The “approve access” page now displays the authorization request in a format that is consistent across all applications.
• Thing types to be authorized are now organized by a simple taxonomy that is the same for all applications.
• The display is no longer dependent on how applications structure their authorization rule XML.
• The display no longer calls out online and offline access separately, except in the case of optional requests. This is based on user research indicating that most users neither understand nor care about the distinction. (Online and offline access themselves have not changed – just the way we display them to end users during authorization.
• For applications that list all data types in one rule, their authorization request will look longer. For applications that list each data type in a separate rule, their authorization request will look much shorter.
• The authorization table has been reduced in size and simplified to hide duplicate or needless data. For example, the “Required” column no longer appears if all the application’s rules are required.
• We will simplify authorization of multi-user applications. If a user selects multiple records to authorize, and if the authorization request is identical for those records, the user will be able to authorize all the records with one click, rather than having to loop through them individually.

.NET SDK Changes

HealthRecordAccessor usability improvements

We have made two changes to the HealthRecordAccessor class to improve usability.

The first change makes it easier to set up filters.

With the previous version of the SDK, it was possible to query all instances of a specific type using HealthRecordAccessor.GetItemsByType(), but when using this method, it was not possible to modify any of the filter parameters before the query was performed. To do that required the following code:

HealthRecordSearcher searcher = PersonInfo.SelectedRecord.CreateSearcher();
HealthRecordFilter filter = new HealthRecordFilter(GeneticSnpResults.TypeId);
searcher.Filters.Add(filter);
// other filter operations

This release provides a new version of CreateSearcher() that accepts a params list of type ids, so that it is now possible to write:

HealthRecordSearcher searcher = PersonInfo.SelectedRecord.CreateSearcher(GeneticSnpResults.TypeId);
// other filter operations

Or

HealthRecordSearcher searcher = PersonInfo.SelectedRecord.CreateSearcher(GeneticSnpResults.TypeId, Weight.TypeId);
// other filter operations

GetItemByTypes() method improvement

The second improvement is to the GetItemByTypes() method.

It is now possible to pass in a HealthRecordView to the GetItemByTypes() method, which is useful to specify the transforms to apply to the returned items, or to limit which versions of type will be returned.

Developer Tools

The HealthVault Application Configuration Center now allows you to create an application directly from the tool, this will make life of folks on non-Microsoft platforms much easier. 

We are adding functionality to make sure the types in the rules editor for access rules shows versioning information for each type, until now folks had to use work around to distinguish type versioning.

Moving forward we will require logo size of 120px by 60 px for applications, this is part of usability improvements. Earlier we recommended size of 140px by 140px, we are planning to convert these logos to the new size and validate the changes with our partners.

Upcoming changes in 0906 Release

In our upcoming 0906 release, we are making changes to the supported list of content encoding for blobs. If you are utilizing the HealthRecordItemSections.OtherData section in the .Net SDK or the data-other section of the thing instance using the XML API, read on because the change could impact your application. As usual, express your concerns in the comments, if any.

I'm affected, can you describe in detail?
Today applications can specify any content encoding for the blob part of items in Healthvault. Using the .Net SDK, OtherItemData.ContentEncoding property supports any encoding and does not enforce any validation on the encoding specified. With Platform 0906 release (expected to release to web by end of June), we are planning on supporting only combination of base64, gzip and deflate encodings for blob data. This change could impacts applications that create health record item instances that utilizes HealthRecordItemSections.OtherData section in the .Net SDK or the data-other section of the thing instance using the XML API. The allowed subset of content encoding for the OtherItemData.ContentEncoding property (or the content-encoding attribute in the thing xml) will be: empty string, null, “base64”, “base-64”, “gzip”, “deflate” OR a comma delimited list of valid encodings, like “gzip,base64”. With multiple encodings, order in the comma delimited list signifies the order in which the encodings are applied to the content.

If an unsupported content encoding combination is specified, Healthvault API returns the following error and will fail the operation.
Error #91 - The content encoding specified for the blob is not supported.

To get around the error, application have to use one of the supported content encodings listed above.

So, why are we making the change?
Allowing a random set of content encodings for blobs put challenging requirements on Healthvault and Healthvault applications ability to easily exchange data. The new encoding enforcement improves predictability on content encoding when working with blob part of Healthvault data.

In future, as we make further enhancements to handling blob data, we are likely to revisit this area and continue to tighten enforcement in the APIs for HealthVault and in our SDKs. We will make sure to give developer community timely warnings on the changes to allow correction of applications.

Microsoft Connected Health Conference

The Microsoft Connected Health Conference will be held on June 10-12th at Meydenbauer Center in Bellevue, WA.

Enter the registration code on the page and choose "submit" to access the details of the conference.

HealthVault 0904 Release Notes

Here are details of our 0904 release  grouped by each of the HealthVault areas.  This release is now available in our Pre Production Envrionment.

Please note this release will be available in our production environment around April 29 timeframe.

HealthVault  Service

Improved Caching and Reliability
We have substantially improved availability and caching in HealthVault: Application will notice more predictable response times under heavy load and better handling of cache server failures at the Healthvault backend.

 

Extended Certificates we trust for Digital Signing
Support for Entrust certificates for Digital Signatures in HealthVault: Beside Komodo, VeriSign and GeoTrust, we now support Entrust certificates for signing HealthVault data.

 

Globalized Application Provisioning Methods
In this release we are adding ability to have localized versions of Applications through our AddApplication and UpdateApplication methods. These methods are available to Master applications for application provisioning.

 

Improved Direct to Clinical Experience
We are adding a customizable Direct to Clinical Success message: Applications will now have the ability to submit a customized success message for the direct to clinical flow.

 

This release will include changes in our user flow for signing up for HealthVault. Please review the details since these changes could affect the way some applications describe and link to our signup process.

 

New first page
In previous version of HealthVault Shell, a new user of HealthVault sees a LiveID signin page that enables the user to sign in using an existing Live ID, create a Live ID or, as an alternative, sign in using OpenID. In ongoing user research, we’ve found that many users don’t know what Live ID is or whether they have one, which can cause unwanted user confusion on the first page of the flow. In this release, users who have not signed in to HealthVault before will see a simpler page that asks them to enter the e-mail address they want to use with HealthVault. If the user enters an address, we’ll check to see if it is already associated with a Live ID. If it is, we’ll show a Live ID signin page that should already be familiar to the user. If it’s not, we’ll show a page where the user can create a Live ID. Of course, users will still have the option to sign in using OpenID instead of Live ID.

 

Some applications host pages that explain to new users what will happen when they create an account. We’ve prepared a screen shot of the new first page of the flow that applications can display on these pages if they wish.

 

 

Streamlined process for creating a Live ID
In previous version, a new user who does not have a Live ID (and who doesn’t use OpenID) must complete a two-page form in order to create one. In this release, we have shortened this to one page.

 

Ability to add records during signup
Users will now have the option to add record(s) during signup, just before application authorization. This may be helpful for multi-record applications in particular.

 

New CREATEACCOUNT target
Welcome the newest member of our Shell Redirect Interfaces - “CreateAccount”.

 

Many existing applications have separate links for new and returning users – for example, a “Sign In” link and a “Get Started” button – that both point to the AUTH target. In this release, we recommend that applications point “Sign In” links to the AUTH target and “Get Started” links to the CREATEACCOUNT target. This isn’t required – sending new users to the AUTH target will still work fine – but it will deliver what we think is a better user experience.

 

Consistent co branding
Co branding will appears on all pages of the flow, including pages hosted by Live ID. We believe this will help make it clear to users that the entire flow is related to using the application.

Data Types
Modification to lab test results type

In response to partner feedback, we have made two changes to the lab test results data type.

1.       The first change is a change in how we interpret the note that is part of a result (in lab-test-result-type). Some existing systems produce results that are intended to be displayed or printed using non-HTML format’s, with hard line breaks and meaningful whitespace.

The new version of the data type now supports that format for this specific Note property. In the HealthVault shell, these notes are rendered using the HTML <pre></pre> tags, and that may be appropriate for other applications that wish to display this data.

2.       The second change was to modify how ranges are expressed. The existing range type only supported a strict numeric range with a minimum and a maximum.

We have modified the range so that the range value is now expressed as a codable value. All applications should put a textual representation of the range in the text property of this codable value. If there is a specific vocabulary for the range (for example, a color range expressed as “yellow – orange”), that can be stored using the coded part of the codable value.

Ranges that are numeric in nature can be placed in the range type. This range type now supports optional value for minimum and maximum, allowing the expression of open-ended ranges by setting one and not the other.

.NET SDK Enhancements

Easier fetching of data instances

In previous releases, if you wanted to fetch a specific instance of a type, you called GetItem(), and passed in the ID and the sections that you wanted to fetch:

        PersonInfo.SelectedRecord.GetItem(itemId, HealthRecordItemSections.Core | HealthRecordItemSections.Xml);

 

It was inconvenient to have to specify the sections and it wasn’t clear which sections to ask for. We have made two changes to make this easier.

First, we have added a Default entry to HealthRecordItemSections, so you can write:

        PersonInfo.SelectedRecord.GetItem(itemId, HealthRecordItemSections.Default);

 

The default is to return the Core and Xml sections.

Second, you can omit the section, in which case the default section is used:

        PersonInfo.SelectedRecord.GetItem(itemId);

 

We added a similar overload to the GetItemsByType() method.

New itemtypes.old assembly

The presence of different versions of a type (for example, Encounter and EncounterV1) has created some confusion. In this release, we have taken all older versions of the types and moved them to a separate dll, named Microsoft.Health.ItemTypes.Old.dll, and also moved them to the Microsoft.Health.ItemTypes.Old.

 

We hope that this will make the set of types easier to understand.

 

If you wish to use the old types, you will need to reference the datatypes.old dll in your project, and reference the old namespace

PPE Environment Server Maintenance – Monday, April 20th, 2009

We will have to perform server maintenance in our pre-production environment (PPE) on Monday, April 20th, 2009. There will be a short downtime between 5 - 6:30pm PST on Monday, April 20th, 2009.

Try HealthVault Shell with Internet Explorer 8

Please try HealthVault Shell with recently released Internet Explorer 8. You can download and install IE8 from here. We would encourage you to report all the issues you come across using HealthVault Shell in Internet Explorer 8 via our feedback site or via a comment to this post. We will try and fix all such issues in our upcoming releases.

Thanks in advance for the feedback!!

PPE Environment Server Maintenance – March 25, 2009

We will have to perform server maintenance in our pre-production environment (PPE) on Wednesday, March 25th, 2009. There will be a short downtime (less than a minute) between 5 - 6pm PST on Wednesday, March 25th, 2009.

Please respond to this post in comments in case you see something unusual apart from the above maintenance. Sorry for the inconvenience.

PPE Environment Server Maintenance – March 16, 2009

We will have to perform server maintenance in our pre-production environment (PPE) on Monday March 16th, 2009. There will be a short downtime (less than 5 minutes) between 5 - 6pm PST on Monday - March 16, 2009.

Please respond to this post in comments in case you see something unusual apart from the above maintenance. Sorry for the inconvenience.

HealthVault 0903 Release Notes

Release notes for 0903

HealthVault Platform

1. GetAuthorizedPeople API 

We are adding a new platform API which will allow applications to get PersonInfo objects of all the authorized people with various filters and a paging mechanism, this is very helpful if you are doing background processing using context of  HealthVault records.

 

The SDK API for this method looks like:

public System.Collections.Generic.IEnumerable<PersonInfo> GetAuthorizedPeople();

public System.Collections.Generic.IEnumerable<PersonInfo> GetAuthorizedPeople(

                GetAuthorizedPeopleSettings settings

);

 

Thanks to our SDET Jenny Xu, we have a sample illustrating how to use this method: http://code.msdn.microsoft.com/GetAuthorizedPeople.

 

2. We are making CCR/CCD/CDA types immutable.

3. We did numerous transform improvements in CCR/CCD reconciliation.

 

HealthVault Shell:

1. We made appselectrecord page an integral part of application authorization process.

2. The CreateRecord target now redirects back to application and also triggers application authorization. This solves a lot of usability issues around account creation and authorization through our partner applications.

3. In printview of a HealthRecordItem shell we will show signature information.

4. We accomplished a lot of accessibility Improvements.

 

HealthVault Data Types and Vocabularies:

No new data types in this release. We updated organization-relationship vocabulary to include "Laboratory".

 

HealthVault .NET SDK:

We are adding a new overload for constructing ApproximateDateTime from DateTime. Paying heed to what Eric was complaining about here:

ApproximateDateTime exerciseDataTimeApprox =
        new ApproximateDateTime(DateTime.Now);

 

Please note: This release will available in production environment week of March 10,2008.

HealthVault 0903 Release Complete in PPE

This morning we completed our 0903 release in pre-production environment. We had some issues between 9:30AM PST- 12:00PM PST. If you are seeing any discrepancies owing to your interaction with the HealthVault platform during this time please contact us (via comments here). We will try to remedy the situation, sorry about the inconvenience.

The good news is that we have the release out now, please try it out and let us know of any issues before we update our production environment with same bits next week. We will soon put up the change log and notes for this release, and the associated SDK.

Upcoming HealthVault release - PB0903

This week we will be deploying what we call - PB0903 release of HealthVault to our Pre Production Environment (PPE). We do not expect this upgrade to disrupt our partners. Next week (week of March 10, 2009), we will update the Production Environment with similar bits.

Once we complete the PPE release this week, we will shortly ship an updated SDK reflecting the changes. So stay tuned, we are looking forward to talk more about the release soon.