As we modify existing HealthVault data types to better meet the needs of our partners, one of the issues we're examining is versioning. Consider the following situation:

Application A is deployed using the current version of the Encounter type (let’s call it V1). Users use the application, and it writes instances of the Encounter type to the user's data record.

Application B then requests us to modify the type. For sake of argument, assume that we decide to add a new field and change the type of a field from string to CodableValue. We'll call this version Encounter V2. We would like to deploy it to the servers so that Application B can now use this new type, but if we do and Application B starts using it, Application B is going to break when it reads Encounter records from Application A, and vice versa.

The solution to this is a new feature that will allow applications to see the view of an object that is correct for the version of the SDK that the application is using, without knowing the actual version of the object. If your application is build using the V1 library, when you query for Encounter objects, the platform ensures that you get the version that your library can understand.

Providing a seemless solution for updates is more complex, and we’ve decided to prohibit cross-version updates (ie V1 cannot update V2 objects), at least for the first release. We believe that updates are rare enough that this is an acceptable restriction.

We had hoped that this solution - which is scheduled to be shipped this summer - would be ready before we needed to modify any of our current data types, but our partners are looking for changes earlier rather than later, so we've come up with a near-term solution as well.

The near-term plan is to explicitly version any type that we need to modify. Using Encounter as an example, we will rename the existing Encounter type to EncounterOld, and then create a new type for the modified type, named Encounter. Your application may need to be modified, depending on how you want to deal with the presence of the new type:

  • If you want to switch over to using the new version, you merely need to recompile
  • If you want to continue to use the existing type and deal with any changes later, you will need to change any occurences of Encounter to EncounterOld and recompile. This will give you identical behavior and you will be able to access any existing Encounter instances stored in the record
  • If you want to support both versions in the same application, you will need to write explicit code in your application to do so

When the versioning work is released, all instances of the Encounter type (or any other versioned type) will appear to applications as if they were the appropriate type.

We regret any extra work or other inconvenience this approach causes for you. If we can help make this transition period shorter or less painful, please let us know.