Interaction Conformance and Versioning - Implementation Issues

Overview

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:

• Message(or Batch).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 Realm-specific (contextual) constraints/substitutions. The value of this attribute identifies the context in question. The constraints/substitutions defined by a realm may not conflict with the constraints as specified by the InteractionId. The realmCode manages the bindings/substitutions of Valuesets and CMETs (and templates and datatype specialisations if and when substitution rules for these are agreed). Each realm has a realm owner: the owner must be an HL7 Affiliate.
  • 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.
  • (Lloyd) I think there needs to be a rule that realmCode is mandatory on the root data element.
• 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 -particularly structural codes-, 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 the time of 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 at the time of 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.
• InfrastructureRoot.templateID: states the constraints (or potentially the extensions) from the standard static artefact model definition that the instance complies to and implements. The constraint applies from the "point of occurrence" in the model. A sender can assert any templateID anywhere they like. It can be ignored by receivers.
  • Note: Profile ids always apply from the root of the message, templateId apply to the "point of occurence".
  • There's no reason to prohibit the declaration of any templates at all, because the declaration of non-recognized templates has no impact on the receiver. Prohibiting custom templates would be similar to prohibiting local extensions, which you're also not allowed to do.
• InfrastructureRoot.typeId: This identifies the actual message type (wrapper, CMET, etc.) used by the sender in constructing the message. The message type applies from the "point of occurrence" in the model. A sender can assert any typeID anywhere they like. It can be ignored by receivers.

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)

(Charlie McKay) Can a conformance profile mandate that particular values of these attributes are present. For example: If you send a weight, you will always include the profiles chosen "weight" templateId. All instances for an interaction will include the "UK" realmCode. TypeId will be populated for all payloads in the profile. My answer to this would be that the profile must be able to express such constraints, but I do not think that we have a balloted or even committee voted resolution to that effect.

Open Issues

Schema versions of an interaction

Note: for the purpose of this discussion, the word "schema" is used for XML schema as well as associated schematron scripts.

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 schema 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. Note: the constraints as present in the documentation haven't changed - only the schema have been changed.

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.

It is certainly important to have schema version information in the schema, and it may be useful to include this in the instance in a comment, maybe only in diagnostic mode -- senders using the wrong specification and/or old weaker schemas is a likely source of trouble in an implementation - so telling the receiver what you are using in a comment does at least provide reassurance / the opportunity to be told that there is something better that you could do. However this should certainly NOT be done using xsi:schemalocation as this may be dereferenced by receiving processors which then try to access the schema file and cause all sorts of problems (file not found errors / processing delays / extra network activity / ...) Charliemccay 05:33, 2 Jun 2006 (CDT)

Another use case is when the older version of the schema contained a bug, which is fixed in the newer version. This will not change the interaction (assuming the bug was purely in the schema). However, receivers might want to check the version of the schema used by sender, in some cases they might even refuse instances produced with the older, buggy schema. Of course having the schema version in a comment has the disadvantage that comments are harder to parse. The argument that schemas are non-normative and therefore need no versioning is in itself not valid; it is common practice in software development to do versioning of all artefacts, requirements, design documents, source code, test scripts etc. Versioning doesn't just apply to normative artefacts, but may apply to all artefacts. Marc de Graauw 9 Jun 2006

I don't think the issue is with schema versioning - any party that releases multiple versions of an object should consider a versionioning system. Question is a) do we have to communicate schema versions in interaction instaces? b) if there is a need to communicate schema versions in a manner other than as an XML-comment, what element/attribute should they be in, taking into account that there may be MT-schema versions as well as IN-schema versions. Rene spronk 06:58, 9 Jun 2006 (CDT)

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?

Answer:

• 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 publication 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.