Versioning and Backwards Compatibility in V3

Notes for V3 Task Force on Data Types and Backwards Compatibility

Version 3 Principles on Compatibility

Document balloted in HL7 in late 90's to express the intended principles for V3. The principles are published as section 5.2 of the Notes to Readers in each V3 Ballot.

Upward Compatibility Among V3

HL7 will provide the maximum degree possible of interoperability among systems operating on older and newer versions of HL7 protocols in the V3 family through compatible enhancement.

• A message structure that is modified in a newer version of the protocol must be acceptable to a system designed for the prior V3 release. However, a system built for the prior release will only extract the information that was defined for that prior release.

• A message structure created in accordance with an older version of the V3 protocol must be acceptable to a system designed for a later V3 release. In some cases, this will mean that the system built for the newer release will not receive certain information fields because they were not a part of the older version of the message structure in use by a specific sender.

• Where compatible enhancement is not possible, HL7 will require evolution in the protocol to happen gradually, so that users can introduce the change into their networks gradually.

• The messages associated with all interactions that are newly defined in a version of HL7 SHALL NOT be sent to a receiver that conforms to the older version.

• A message structure MAY be declared obsolescent in one release, with a stated alternative message structure. Both the obsolescent message structure and its alternative can be used by all systems supporting that release.

• The obsolescent message structure MAY be declared obsolete and dropped when still another HL7 version is issued.

• An obsolescent message structure SHALL NOT be declared obsolete for at least two years from the date of the version that first declared it obsolescent.

The above notwithstanding, if a new Implementation Technology Specification (ITS) is introduced, HL7 may specify that conformance to the ITS does not require dealing with message structures that are obsolescent when the new ITS is introduced. To the maximum degree possible, these restrictions should not impose limitations on the evolution of the overall reference model. There are no restrictions on making changes to the information model if those changes do not impact the message structures that were described in a prior version of the Standard.

Actual "Versioning" in V3

Subsequent to the V3 Principles approval, HL7 undertook the development of V3 specifications. The strategy that was followed was to seek "parallel" development and balloting of the V3 standards. Under this strategy, each of the involved Work Groups would develop and seek approval for its own "domain" content, and the combined effort to become the "V3 Messaging Specifications". Subsequent to the first approvals of the three specifications, the Modeling and Methodology Work Group is all the notion of publication "packages" known as editions. In essence, each ballot and constitute an "implementation edition", and an annual "Normative Edition" would be produced as the formal specification which implementers were expected to use.

Since 2005, there have been seven "Normative Editions" published by HL7. Each has been self consistent, and the expressed intent from Modeling and Methodology has been that implementations should be made from content drawn solely from one Normative Edition. Thus, implicitly, the transition from one edition to a subsequent addition that might be "non--compatible" would be accomplished by using an earlier Normative Edition as the "obsolescent" messages, and a later Normative Edition as the "newly defined" set of messages.

To be clear, this was never, previously, expressed relative to the obsolescence principles cited above.

Implementation of "Deprecation" in the Reference Information Model

In order to support the concepts embodied in the V3 Principles, including the notion of "obsolescence", the management of the HL7 Reference Information Model, and its associated vocabulary, adopted the notion of "Deprecation" to support the gradual adoption of "breaking" changes in the RIM.

Whenever a "breaking" change was is proposed, such as the removal of an attribute, it was adopted with the following steps and expectations:

1. the element to be removed would be listed as "Deprecated" as of a particular date and release of the RIM

2. the deprecation notations would contain a statement as to how to represent the "semantics" of the deprecated element in future models. (This might include identification of a new, replacement element, or of an alternate design structure and accomplish the same thing.)

3. Effective with the date of deprecation, he selected element was "not to be used in the development of any new models." (To be clear, the meaning of "new models" was never fully explored. For example if a previous model was developed prior to deprecation, and was subsequently modified within the context of a second ballot, did this constitute a new model?)

4. Subsequent to deprecation, the element was to remain part of the RIM for at least two Normative Edition. Subsequent to that time, the deprecated element could be removed (deleted) from the RIM.