Versioning and Backwards Compatibility in V3

From HL7 TSC
Revision as of 15:43, 16 October 2012 by WoodyBeeler (talk | contribs) (Created page with '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…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.