HL7 Version 3 – Substantive Changes

HL7 V3 Substantive Changes

1. Purpose

The purpose of this document is to give guidance to Technical Committee (TC) Chairs in determining whether a change to a v3 balloted document is substantive. This document provides some general principles as well as specifics and examples of what is and what is not a substantive change. It also provides some reference on the role substantive change plays in the HL7 balloting process.

2. Introduction

What is a substantive change? According to the American National Standards Institute (ANSI) a substantive change is defined as one that directly and materially affects the use of the standard. ANSI also provides the following examples of substantive changes:

  • “shall” to “should” or “should” to “shall”;
  • Addition, deletion or revision of requirements, regardless of the number of the changes.
  • Addition of mandatory compliance with referenced standards

The ANSI definition includes changesthat would break solutions that were implemented using the specification as it existed before the change.

The ARB believes that substantive changesare those which modify the standard by adding or removing capabilities. Any change which damages the integrity of semantics aswell as the validity of syntax is a substantive change.

3. Substantive Changes and the HL7 Balloting Process

The goals of the HL7 ballot process are:

  • HL7 wants to meet its members needs for specifications that areresponsive to conditions; timeliness is important
  • HL7 wants to develop specifications that permit any interested HL7member to participate and make their views known.
  • HL7 wants to encourage early implementation of specifications toensure that final specifications are used and useful.
  • HL7 wants to publish high quality specifications that are accurate,clear, coherent, and consistent across the full set of specifications.
  • HL7 is governed by ANSI "rules" that are focused on ensuring that a consensus is achievedwithin the entire industry without any "special interests" skewing theresults.
  • HL7 bylaws, policies and procedures interpreting them, are intendedto achieve these goals.

The definition of "substantive" changes needs to be interpreted within thiscontext.

In a perfect world, every specification submitted for ballot would be complete,coherent, clearly expressed, consistent with all related specifications anddelivered "just in time" for it's intended use. Ballot reviewers wouldrepresent the full spectrum of affected parties and would vote in theaffirmative with the only comments being small suggestions to add "polish"before publication. Additionally, many peoplewould implement the specifications and actively provide feedback to continueto extend and enhance the specifications.

We realize that we do not live in a perfect world. Each of us jugglesmanyobjectives. The tradeoffs are tough and it isthe Architecture Review Board's responsibility toprovide fairly fine grained guidance to the TCs so that the overall set ofv3 specifications approaches this ideal. The ARB has been approached by TCs forinterpretation when they cannot clearly delineate changes as either"substantive", "non-substantive". The 2.x list of substantive changes is based on the premise that changes that would "break" solutionsthat were implemented using the specification before the change was made are substantive. The ARB will apply this principle to V3, as well.

Since the goal of v3 Standards is semantic interoperability,the overriding principle for determining substantivity will be whether a change damages the integrity of semantics or the validity of syntax. A primary V3 principle is the use ofconstraints as the delineation of correctness. Adding tighter constraints does not break the semantics, however, loosening constraints does. Since the v3specifications are model driven, changes to any of the structuralproperties that would loosen the constraints contained in the source models must bedeemed a substantive change.

4. The Importance of Substantive Change

Why is the distinction between substantive and non-substantive important? ANSI rules and HL7’s bylaws require that all substantive changes are balloted. For example, if a substantive change is made to a document that is being balloted at Committee Level 2, the substantive changes must be balloted at Committee Level 3.

The identification and designation of changes as substantive or non-substantive plays an important role in the balloting process. When a TC creates a ballot package, the package should include a list of all changes from the previous version of the document. This list should indicate which changes are considered to be substantive, and which are not. When a chapter or other section of a standard goes through successive ballots, this list should indicate changes from the prior ballot, not from the beginning of the balloting process.

5. Examples of Substantive Changes

Examples of substantive changes in Version 3 include:

  • Loosening or removing constraints on data
  • Adding or deleting a trigger event.
  • Addition/deletion/change of an RMIM
  • Changes to an RMIM constitute addition, removal of a class clone, association to a class clone, attributes of a class clone.
  • Changes to the characteristics of an attribute within an RMIM, HMD, message type.
  • For example, C/Q made changes that remove three message types, and replaces them with one. The three Message Types were very similar and were combined into a single message that has all the features of the previous three.
  • Changing the properties of an existing datatype
  • For example, Add a property to AD to indicate the parts are unordered.
  • Changing the value set assigned to a structural table
  • For example, Use of an HL7 defined vocabulary instead of xml:lang for coding languages. This is non-controversial, but substantive.
  • Changing definitions that change receiving system behavior
  • Changing text that alters trigger event rules
  • In the unlikely event that changes to descriptive text cause a difference in the way that message senders and receivers processed the message, this would be a substantive change.

6. Examples of Non-Substantive Changes

Examples of non-substantive changes in Version 3 include:

  • Change or add Storyboards
  • Change or add Application Roles
  • Change or add examples
  • Changes to descriptive text that clarify, but do not change meaning
  • Typographical corrections
  • Formatting Corrections
  • Correcting or adding hyperlinks to supporting documents. For example, the CDA document refers and links to RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)" If the RFC moves, the hyperlink would break. Fixing a broken hyperlink is a technical correction and a non-substantive change.
  • Changing the name of an attribute in encounter class specialAccommodationsCd. This is really a special needs code. …. This is strictly a change in name, not in definition. Would this be considered a substantive change? … The ARB viewed this as a clarification that followed the consensus process.
  • Correcting a change of destination CMET. The framers of the ballot had intended to point to the CMET changed to all along – there was an incorrect entry in the cmetinfo.txt file. This is an example of a technical correction.
  • Change to cardinality between control act and payload. Going from 0..1 to 0..* This change will not break existing implementations,

7. Definitions

7.1 Backwards Compatibility: A change that would create a backward compatibility problem is a substantive change. For backwards compatibility, a message receiver is expected to receive a new message and be able to ignore added material.If there is new material that needs to be parsed in order to process the message given its new definition, the change is substantive.

Some general rules for a Backwards Compatible Ballot Package are:

  • From the v3 perspective, the focus is on message types. As long as there is a set of message types that do what was done before, the contents of a ballot are backwards compatible.
  • Neither attributes nor associations can be removed from a message type.
  • Association cardinality cannot be tightened.
  • You can change attribute conformance from Mandatory to Required, and from Required to Optional, but not the reverse.
  • You cannot remove values from the HL7 defined value sets for structural codes. This includes all attributes with CS datatypes.
  • If a particular coding system is associated with a domain within the ballot, it may not be removed.
  • If a particular value set is associated with a domain within a ballot, the value set reference may not be removed, nor may any code be removed from the value set.
  • No interaction may be removed that existed in the prior ballot. This precludes removal or redefinition of a trigger event.
  • Receiver responsibilities may not be removed from interactions.

7.2 Non-Substantive: The ARB considers a change to benon-substantive if it would not cause an interface to fail when a message was sent or received.All technical corrections are non-substantive changes. Only non-substantive changes may be made to a DSTU.

7.3 Substantive: Substantive changes modify the standard by adding or removing capabilities. The ARB considers a change to be substantive if it would cause an interface to fail when a message was sent or received. This is similar to, but more expansive than, the definition of backwards compatibility. A change that creates a backwards compatibility problemis substantive by definition.

The ANSI Definition of Substantive Change is:

A substantive change in a proposed American National Standard is one that directly and materially affects the use of the standard. Examples of substantive changes are below:

  • “shall” to “should” or “should” to “shall”;
  • Addition, deletion or revision of requirements, regardless of the number of the changes.
  • Addition of mandatory compliance with referenced standards

7.4 Technical Correction: A technical correction is a non-controversial change that alters the document so that it says what the committee intended to say. Technical Corrections include fixing typographical errors and other minor, cosmetic changes. A Technical Correction is a non-substantive change.

8. References

8.1 HL7 Balloting Process

The full process is detailed in the HL7 Policies and Procedures Manual.

8.2 HL7 Bylaws

The relevant portion of the HL7 Bylaws is Article 15, which states:

ARTICLE 15 - PROTOCOL SPECIFICATIONS BALLOTING PROCEDURES AT THE FULL HL7 VOTING MEMBERSHIP LEVEL

15.01 SUBMISSION OF ITEMS FOR FULL MEMBERSHIP BALLOT

15.01.02 BYPASSING TECHNICAL COMMITTEE BALLOT RECONCILIATION - A technical committee chair may, with the concurrence of the Technical Chair, submit an item to the full HL7 voting membership for balloting prior to technical committee consideration of the negative votes on that item. The submission shall include items (1), (2), and (3) of 14.7.1 and the technical committee chair's reasons for proceeding in this manner.

15.07 NEGATIVE VOTES NOT PREVIOUSLY CONSIDERED

15.07.03 SUBSTANTIVE CHANGES – The Technical Committee shall assess substantive changes suggested by a negative ballot response for viability and impact with the objective of determining whether the changed specification may move forward to a subsequent Membership level ballot or must be re-balloted at the Committee level under Article 14. The Technical Chair must concur with a recommendation to initiate a subsequent Membership level ballot without re-balloting at the Committee level. The original consensus group shall be notified of actions taken regarding such substantive changes.

8.3 Changes Set Diagram

One can consider all changes made to a ballot document to be set. All changes are either substantive or non-substantive. Substantive Changes include all Backwards Compatibility Issues. Non-Substantive changes include all Technical Corrections. The following set diagram illustrates the relationships.

Architecture Review BoardPage 112/6/2018