HealthVault 1009 Release

Welcome to the fall release of HealthVault!

Figure 1. Courtesy Of Bing Images

HealthVault 1009 release is now available in the  HealthVault pre-production and production environment.

The associated version of .NET SDK is available here. Please note the Assembly version of .NET SDK for this release is 1.1.2193.4712 and File Version is 1.5.2485.5808. This is a functional release and doesn’t break the previous release.

Following are some of the features and improvements done in this release :

Consistent Record Ids

HealthVault Platform now assign the same record-id to the same user in context of the same application. This behavior supports the authorization, de-authorization and sharing scenarios for the same user. Unlike the old behavior, now applications can rely on using the record-id to identify the user, when the same person authorizes or de-authorizes the application multiple times.

Revising Handling Of Singleton Types

The HealthVault platform has revised its handling of singleton types. We don’t allow a user to mark a singleton type as personal. We taken this stance to enable the applications to handle this type correctly, if user doesn’t want to share this type they can do it at the application authorization step.

Fig 2. Singleton types can’t be marked as personal.

CCD Import and Export Improvements

Import and export of CCD documents has been greatly improved. 

HealthVault now supports import to and export from the following HealthVault data types: Condition, Family History, Payer, Advance Directive, Vital Signs, Procedure, Encounter, Blood Pressure, Lab Test Results, Height and Weight.

 

Better Discoverability For Fax and Data Conversion services

Currently, HealthVault partners provide solutions to help users to store their paper medical records in a structured way in HealthVault. However these service were not discoverable. As part of 1009 release, we have exposed the maxemail and Unival services on the HealthVault Shell homepage so that consumers can leverage these services to get their health information faxed directly into their HealthVault account, and get those paper records converted to structured information through professional conversion services.

Fig 3. HealthVault Shell Landing page with Fax and Data Conversion services.

Better Support For Versioned Types In .NET SDK

HealthVault is constantly evolving its data types to support partner needs. In some cases this requires versioning a data type so that two (or more) versions of the same data type live side-by-side. See https://blogs.msdn.com/b/healthvaultdatatypes/archive/2008/04/14/data-types-and-versioning.aspx for more information on how HealthVault continues to make all data of a given type available to applications regardless of the version the application is using.

After receiving feedback on our data type versioning design, some changes were made to the .NET API to better support the expected behaviors of queries against HealthVault and to better support live updates of applications in a server farm.

Better support for expected behaviors of queries

The HealthVault type versioning design uses the applications configured authorizations to determine which schema version of a type to return to an application if the TypeVersionFormat wasn't specified. Although this is a robust design, most application developers expected that the version of the schema being returned would match the type identifiers put in the filters of the query. This release of the .NET API addresses this issue by putting the filter type identifiers into the TypeVersionFormat collection automatically.

Support live updates of applications in a server farm

Let's say you have a HealthVault application using the Encounter type and you have multiple servers running your web application. Now let's say that the HealthVault team decides to version the Encounter type to support more scenarios which results in EncounterV1 and Encounter types being available. You want to upgrade your application to the new Encounter type (V2) but don't want to have any application down time.  You download the new SDK and update your code to the new version of the type. The current type versioning design requires that you change your application authorizations to the new version of the Encounter for this to work, so in the PPE environment you do just that and test your code thoroughly.  Now the big day comes to take this new version live.  To do this you take a server out of rotation on the load balancer, upgrade it to the new version of your application and the HealthVault SDK.  If you put it back into rotation then any requests to this server will be broken because the application will be receiving EncounterV1 instances until your application authorization configuration is updated in the PROD HealthVault environment.  However, you can't update your configuration until the other servers get the new version of your application or they will be broken.

To support this scenario, the HealthVault .NET SDK now supports a new configuration value called "SupportedTypeVersions".  This key goes in your web.config file and contains a comma separated list of the class names for the types that server supports. This list gets automatically parsed and converted into the type identifiers for the types supported by your application and gets automatically populated into the TypeVersionFormat list when queries are made to HealthVault. You can now add the new version of the type to the "SupportedTypeVersions" configuration value when upgrading your servers prior to your application authorizations changing and they will get the correct version of the type instances back. Once all your servers are updated you can either remove the configuration or keep it there for added level of comfort. At this point you should also change your application authorizations to specify the new version of the type.

For those applications that are experience performance issues or need to leverage the legacy behavior, the "UseLegacyTypeVersionSupport" configuration value can be set to "true". Also note this is the default behavior for this release as well.

Device Directory Editing in Application Configuration Center

Partners can now enter device information in a friendly way through Application configuration center.

Fig 4. Device Directory editing in Application Configuration Center

Tool Tips In Application Configuration Center

We added tool tips in Application Configuration Center so that developers can better navigate the configuration properties for their applications.

Fig 5. Tool tips in Application configuration center