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