The objective is the same as for V2 – anyone materially affected by a change in the normative specification should have an opportunity to make their opinion of the change known, and have that opinion taken into consideration, before a change is adopted.
Those potentially materially affected are not just senders and receivers of messages – but consumers of ANY HL7 specification. Operationally, if implementing against the specification as previously communicated does not accomplish the same objective as implementing against the current specification, the introduced change is substantive.
Substantive differs between Version 2 and Version 3 in the increased emphasis on the “semantics” of the interaction, not just the syntax. Therefore, if any system participating in an interoperable function cannot meet its contractual obligations, the introduced change is substantive.
Because V3 has more artifacts and is more explicit, there is more probability that ANY introduced change will be substantive, unless it was just a change to definition to improve clarity. The following are examples of substantive changes:
- Changing constraints on data.
- Changing the properties of an existing data type - 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.