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.
- 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);
// 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
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.
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.