Partager via

HealthVault PB9 release

  • Article

Hot on the heels of the PB8 release that brought improvements to the shell, PB9 has been deployed to the HealthVault servers.

The release contains the following new items:

  • A change in access to previous versions of data instances
  • Determining what records have changed
  • Client Id
  • Group membership
  • Versioning information
  • The BodyDimension data type
  • An updated FamilyHistory data type

 

Access to previous versions of data instances

We  found that platform behavior with respect to old versions of items that have been updated ran counter to the expectations real users had in their minds when granting application authorization. As a result, we’ve changed the authorization model so that – other than the auditing functionality in the HealthVault Shell -- applications will no longer be able to request these old versions. Note that this does not impact the ability for applications to compute or determine data integrity. Applications will still have full access to the current “audit” metadata on items, so they can determine if data has been changed and if so, by who.

This change removed the capability for an application to traverse all versions of an instance to find the original creator. This information is now available on the Created property of the instance, available if you ask for audit information when you fetch the instance.

Determining what records have changed

Previously, an offline application doing synchronization would need to query all the data in a HealthVault record to look for possible changes to the record. The new ApplicationConnection.GetUpdatedRecordsForApplication() method will return a list of all the records ids that have changed since a specified date. The application can then check those records rather than all records.

Removing Application Authorization

Applications now have the ability to remove their authorization to a HealthVault record.  Previously, this could only be done through Shell by the person who granted the authorization.  This is most useful to applications that, for whatever reason, need the ability to completely revoke their access to a HealthVault record.  The functionality can be accessed via a new XML method RemoveApplicationRecordAuthorization or the SDK method - RemoveApplicationAuthorization() - in the HealthRecordAccessor class.

Client Id

Previous versions of the platform have supported linking together individual instances using the CommonData.RelatedItems collection on an instance.  This worked but was inconvenient because each object had to be uploaded to HealthVault to get the key that was placed in the related item collection. This made it inconvenient to link two items to each other because you would need to add one, add the second one related to the first, and then update the first one so it was related to the second. This became worse as the number of items involved increased.

Concurrently, we’ve been doing some data type redesign that will require HealthVault connection center to create items that are related to each other, and because of architectural limitations, it is unable to use the current scheme.

So, we’re extending our current approach with a “client id”. It is conceptually similar to related items, but the relationship is set by the client before the object is saved in a health record, and therefore avoids the problems with related ids. The client id is exposed as a string in CommonData.ClientId, and can be set to a globally unique value (Guid.NewGuid is fine for this).

The HealthRecordItemRelationship class has been extended to store either a instance key or a client id, so setting up the relationship and following it is very similar.

Fetching an instance based on the client Id is performed by adding the id (s) to the HealthRecordFilter.ClientItemIds() collection, and executing the filter.

There will be more information and sample code in the near future.

Group membership

The group membership scenario is now fully supported. See Using the Group Membership types for more information.

Versioning information

There have been several additions to allow applications to better understand how types are versioned.

HealthRecordItem.IsUpVersioned indicates where the instance that the application has is a newer version than the one that is stored in the user’s record.

The HealthRecordItemTypeDefinition.Versions collection details all the versions for a specific type.

More information on versioning in general including source code and best practices will be available in the near future.

The BodyDimension data type

The BodyDimension data type is designed to support two scenarios. It can store length and head circumference in a pediatric scenario, or it can store general dimension, typically used in fitness or weight-loss tracking.

An updated FamilyHistory data type

The FamilyHistory type has been updated, combining the information that had been split out into FamilyHistoryPerson back into the base type.

Comments