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
