This wiki has undergone a migration to Confluence found Here

Interaction Conformance and Versioning - Implementation Issues

From HL7Wiki
Jump to navigation Jump to search


The Dutch AORTA programme is in the process of creating a nationwide infrastructure for the exchange of data between healthcare providers. AORTA uses HL7 version 3 messages as its core mechanism for information exchange. The initial specifications have been created in 2003. In 2006 the infrastructure will be used in production in at least 2 regions.

The specifications (both for the architecture as well as the HL7 v3 messages) have been mostly created in a bi-annual cycle. The HL7 messages are mostly based on Ballot 7; parts of later specifications have been pre-adopted and included in the AORTA specifications.

Because of the fact that the current specifications effectively are the first ones to be widely implemented, and the fact that all specifications are subject to change, the issue of versioning and conformance is raised – an area where there are many issues yet to be solved or clarified.

High Level Issue

At a high level of abstraction the question is how we can ensure that the receiver of a message is aware (in as precise a way as possible) what the semantic intent of the sender was. This includes the static model and vocabulary, the dynamic model, and constraints.

If we were to specify a checklist of what a receiver should look for in order to establish the semantic intent of the sender the checklist would look as follows:

  • InteractionId: the interactionID identifies the static models (wrappers and payload(s)), the dynamic model, and constraints placed upon them. The interactionId for normative and DSTU artifacts includes a version component which in turn refers to specific versions of the static models and dynamic model constructs.
  • Message(or Batch).realmCode: this attribute signals the imposition of context (realm)-specific constraints. The value of this attribute identifies the context in question. The constraints defined by a realm may not conflict with the constraints as specified by the InteractionId. Constraints include vocabulary domain binding, CMET substitution and potentially datatype substitution.
    • Note that in the Dutch context this attribute won’t be used anywhere else in an interaction – if the realmCode is used at the root class of the interaction it applies to all classes in the interaction. However, in some cases, realmCode may switch within an instance. E.g. A Canadian claim message referencing a U.S. realm clinical act.
  • Message(or Batch).profileId: states the constraints (or potentially the extensions) from the standard message definition that the instance complies to and implements. When multiple profiles are specified, the message instance must be valid against all of them. However, a receiver may choose to validate against only the first one recognized. For this reason, 'preferred' or more-rigorous profiles should be listed first. The constraints defined by a Profile may not conflict with the constraints as specified by the InteractionId or the Realm.
    • Note: for v3, profiles can’t be (fully) expressed in a computable fashion yet; a MIF based mechanism has been defined but not yet confirmed and there is no tooling which yet supports it
  • Message(or Batch).versionCode: infrastructure versioning (CMETs, datatypes, vocabulary, transports) is communicated using the versionCode attribute and has values such as "2006NormativeEdition". The versionCode indicates "all infrastructure stuff that was normative as of the point and time the normative edition was released". For early adopters, it could be one of the development editions or an equivalent "packaged release" by a particular realm. See Interaction Versioning for details.
    • In the case of vocabulary, some domains may be marked as "fixed at publication" while others may be marked as "mutable", meaning that they change over time. E.g. The set of drug codes expected to be supported are those published by the local regulatory agency at a given time, rather than those which happened to exist at the time the publication was issued. The specific mechanism by which "fixed ad publication" vs. "mutable" will be documented in the vocabulary specifications remains to be resolved.
    • Note: the UK MIM uses this attribute to identify their publication edition, e.g. their equivalent of “2005B”. In the UK a reference to a HL7 Edition doesn’t make sense given that artifacts are inspired by, but not constrained versions of, universal artifacts as contained in an HL7 Edition.
  • templateID: This serves a similar purpose to profileId. However, it only affects the constraints (extensions) on the static model, and only applies from the "point of occurrence" in the model. (Profile ids always apply from the root of the message.) It can be ignored by receivers.
  • typeId: This identifies the actual message type (wrapper, CMET, etc.) used by the sender in constructing the message. It can be used in a similar manner by templateId.

AORTA uses the above HL7 mechnisms in the following manner:

  • If an interaction has not been extended from the universal interaction AORTA uses the universal interaction identifier. Dutch specific constraints have to be conveyed as realmCode and profileId. Interactions which have been extended in a non backwards compatible fashion have been assigned interactions with a “NL” realm identifier.
  • The realmCode will be “NL” to identify that realm specific constraints as defined by HL7 Netherlands apply, this is especially needed to extend or otherwise change value sets for HL7 vocabulary domains.
  • The versionCode indicates "all infrastructure stuff (CMETs, datatypes, vocabulary, transports) as of the point and time the release was published". AORTA is based on the "Ballot 7" Release, even though some parts of the models as well as parts of the schema are based on ITS versions later than ballot 7. It currently contains "NICTIZEd2005-Okt" to indicate this unique mixture of models/ITSs as used in the current project.
  • The profileId can be used to identify the set of AORTA documents (two releases a year, e.g. 2005B and 2006A), these contain a full description of the v3 artifacts and the context specific constraints played upon them. Additional repititions could identify vendor or product specific constraints (a further constraint of the constraints as defined by AORTA)

Open Issues

Schema versions of an interaction

Consider the following scenario:

  • The 2005B publication of AORTA contains the description of an interaction ABCD_IN000001NL and the constraints placed upon it. A schema ABCD_IN000001NL.xsd is published as well, and is published jointly with the 2005B publication. The schema is not normative, vendors are free to use other schema as long as their messages also validate against the published schema.
  • The schema may not enforce (all of) the constraints as defined in the 2005B publication (e.g. the XML ITS is not able to enfore everything, the universal model used to generate the schema had not been localized, there is no constraints language). After publication of the 2005B cycle some changes are made to the schema to enforce some of the constraints.

Question: do we need versioning of the schema, and to inform the receiver of the interaction what version of the schema was used?

Answer: No. The sender defines conformance against abstract models. If the 2005B specification specified that attribute A shall not be used, and schema version X allows it, a sender is not allowed to populate the attribute. Creating a schema version Y which disallows the use of attribute A serves as a technical aid to enforce the constraint, a change in use from schema X to Y doesn’t have any impact on systems which conform to the 2005B specification, and therefore identification of the schema version is of no relevance.

Interaction versioning vs using a new Interaction

Question: when should a new interaction be created, and when should an interaction just be published using a new version number?

  • If between publication 2005B and 2006B a non Semantically Backward Compatible change is made to an abstract model or constraints thereupon then per the Interaction Versioning rules a new identifier has to be assigned to the artifact.
  • When dependent models of the Composite Message model (e.g. CMETs, Vocabulary, Datatypes) have been assigned a new version, the interaction must be assigned a new version as well.

Note: The UK MIM specification appears to use the version part of interaction identifiers (SSDD_INnnnnnnRRvv) to identify versions of the original artefact – irrespective of whether these changes where Semantically Backward Compatible.

Digital Signature requirement

Question: what is the impact on versioning if we add the requirement (at some point in time) that all messages need to have a digital signature?


  • This is likely to be introduced as part of a specific publication cycle (let's call it 200XA). If an interaction references 200XA (or a later version) in its profileId, then it also contains a digital signature. From the moment publ,ication 200XA comes into effect all receiving applications shall reject interactions that claim conformance to publications prior to 200XA.
  • The only alternative is to regard this requirement in the same manner as a change in the dependent models of the Composite Message model (e.g. CMETs, Vocabulary, Datatypes), but that would be stretching the definition of dependent models too far.