Clever Geek Handbook

FHIR migration and backward compatibility

As systems developers, we are faced with a dilemma when we move from one version of FHIR to the next. We started using FHIR 0.0.81 and then moved to SVN 2833 on September 10, 2014 to include a bug fix. As suggested, we downloaded the Java code from the SVN trunk and followed the directions on the FHIR Build Process page .

FHIR 0.0.82 Incompatibility

Now that FHIR 0.0.82 is available, we want to move to the released version. However, after downloading 0.0.82, we noticed that several resources, such as Destination, which were in trunk rev2833, are not in the 0.0.82 release. This leads to our first questions:

  • What does the connector contain if it doesn't contain the latest code for the next release?

  • Should anyone use what's in the trunk?

  • Is there a release branch from which 0.0.82 was created?

Incompatibility of external lines

Since our code has dependencies on resources injected on the backbone but not included in 0.0.82, we must continue to check the FHIR directly from SVN. On October 21, 2014, we uploaded SVN Java code version 3218. When we integrated this code into our system, we discovered numerous compatibility issues. Here are some of them:

  • The various Enum values ​​range from lowercase to uppercase, including Patient.AdministrativeGender and HumanName.NameUser. While conforming to the Java naming standard is a good idea, changing the underlying data types breaks compilation.

  • The method names have changed, which also leads to compilation errors. We also found that there were concurrent name changes. For example, in the HumanName class, the old setTextSimple (String) is now set to Text (String), and the old setText (StringType) is now set to TextElement (StringType). Both the name and type of the setText () parameter changed, which caused a migration error, because each time you use it, you have to decide whether to change the method or its parameter.

  • The ResourceReference resource type has changed its class name. In the FHIR model package alone, 859 ResourceReference events in 61 files were affected. This does not include changes that are interleaved with other FHIR packages, or changes that will pulse through our application code and our database schemas.

  • We notice several new resources in trunk rev3218, including the NewBundle. Previously, we assumed that bundles should be resources, so it's great to see this change. However, since the backbone is not backward compatible with 0.0.8x releases, I'm not sure if we will have to support both the old and the new way of parsing and packaging JSON and XML.

To be more precise about things, it's important to recognize that some of the above FHIR changes not only affect compilation, but can easily introduce subtle runtime errors. In addition, FHIR changes may require database schema changes and data migration in some applications. For example, our application stores JSON resource streams in a database. Something as simple as changing the enumeration value from "male" to "MALE" requires migration utilities that update existing database content.

Forward

We invest heavily in FHIR; we want it to succeed and be widely accepted as a standard. For this to happen, backward compatibility and version migration issues must be addressed. It is in vain that any light that can be shed on the next question will make us all move forward:

  • What is the purpose of the 0.0.8x line of code? Who are its target users?

  • What is the purpose of the trunk code? Who are its target users?

  • Is 0.0.8x users expected to migrate to the base codebase?

    • If so, what migration strategy will be used to resolve many of the incompatibilities between the codes?

  • What is the code deprecation policy in each codebase?

  • What level of backward compatibility can you expect from revision to revision of trunk code?

  • Is there a FHIR roadmap that system designers can use to plan their own development cycles?

Thanks, Rich C

+3


source to share


2 answers


My apologies for not documenting how version control affects Java reference implementation anymore. I will do it. I assume that you are familiar with version control policy: http://hl7-fhir.github.io/history.html

There are currently two versions of FHIR. The first is DSTU 1. This is a fork in SVN ("dstu1") and only changes for significant bug reporting. The reference implementation is supported and backward compatible. The second version is the version of the connecting line, in which we are preparing for the release of the second version of DSTU. At the moment svn is very unstable - constantly changing, and we change changes several times several times as we consider different options in the committee. Also, there are several big changes between DSTU1 and the trunk, and more and more. Therefore, you shouldn't expect that switching between the DSTU1 and the trunk will be painless. Also, developers should not be using the trunk unless they are truly bleeding (and tightly connected, like a skype implement pipe).When the trunk is stable and we think it's worth releasing a beta to developers, we update versions and version history and release here:http://hl7.org/implement/standards/FHIR-Develop/ and release the maven package for that version.

In the torso, since a lot of changes have been made, we also changed the constants to uppercase and reversed the way we create / set properties. Agree that it has a price, but there was already a price to switch from DSTU1 to the trunk. And when I make a beta (soon, actually) I update the Java reference implementation number, etc. Note that Java constants have moved to uppercase, but wire format constants have not changed, so the stored json streams are fine (although broken by many other changes in the spec)

Given the volume of changes between DSTU 1 and the backbone (there is no list of them yet, I'll have to prepare this when I update the beta), you should expect an extensive rework for the transition. I currently maintain one source that implements a server for both (in Pascal, http://github.com/grahamegrieve/fhirserver ), but I suspect this approach is about to get broken by a change that NewBundle introduces.

So, specific answers:

  • What is the purpose of the 0.0.8x line of code? Who are its target users?

Support for users of the existing DSTU1 specification

  1. What is the purpose of the trunk code? Who are its target users?

preparing to become DSTU 2. It should be more stable in a few weeks - as soon as we start making backward incompatible changes, we are trying to get as many of them as possible now

  1. Are 0.0.8x users expecting to migrate to the underlying database?


yes, when DSTU 2 is released or at least when we start to have trunks on the trunk version, prepare for DSTU2 (the first one is scheduled for January)

  1. If so, what migration strategy will be used to resolve many of the incompatibilities between the codes?

There will be a lot of code rewriting. We can free the xml transforms to move resources from DSTU1 to DSTU2 when this is complete, but that might not even be possible.

4a. What is the code deprecation policy in each codebase?

DSTU 1 is extremely conservative. the trunk will be settled, although stability is never guaranteed. Beta versions will be instant releases.

  1. What level of backward compatibility can you expect from revision to revision in trunk code?

No, really, at the moment.

  1. Is there an FHIR action plan that system developers can use to plan their own development cycles?

Well, in addition to the versioning policy mentioned above, there is this: http://www.healthintersections.com.au/?p=2234 (what was it for you, no?)

+3


source


As an addition to Grahame's answer: There is only one highlighted bold link in the Docs tab of the spec - Read Before Use . This page, which attempts to clarify that the DSTU promises release is not forward and backward compatible. This cannot - the whole purpose of the DSTU is to collect feedback from the implementation on what significant changes are needed in order for the standard to be ready to be locked in stone when we go regulatory. If we promised forward and backward compatibility in the DSTU, we would be stuck with any decisions we made during the initial project, whether they turned out to be good or not.



0


source






More articles:


All Articles