XML ITS design principles

As the XML ITS is maintained, and other ITS specifications are developed it seems that it would be useful to have a baseline of the principles that were followed for the first HL7v3 ITS.

These were approved by INM 5/6/06 on a conference call as a true account of the design principles that were used for XML ITS.

The design principles that were followed to produce the release 1 XML ITS were:

• The transform from the abstract model to the instance should be as simple as possible.
• The instances should be pleasing to the eye of a human reader.
• Names should be determined in the abstract model, not generated by the ITS
• Without compromising the simplicity of the model-instance transform the instances should be as small as possible. Thus XML attributes were used for datatype components.
• The ITS should define the set of valid instances for a V3 artefact, NOT the schema that must be used. This is to allow for stability of the instances as schema techology improves, and also allows for the use of different schema for different uses. (see below)
• The ITS should allow for the use of W3C schema for validation and message description.
• Use attributes to support the population of PSVI.
• CMET references and Wrapper boundaries should be transparent in the instance. Thus it should be possible to re-package the way that an interaction is defined by mergeing two wrappers, without that affecting the instances. (see below)
• Choices should be transparent in the instance - thus a class should appear in the instance in the same form whether or not it is part of a choice. This is to allow for forwards compatability when choices are introduced into models and to reduce the level of nesting

FAQ

Why is the interationID used for the root element name?

• This was introduced so that schemas for multiple messages could be included in a single schema cache or WSDL file without element name clashes, and so that the interaction could be identified on the root element, rather than having to read into the file. As in so much, what is easy for some is a frustration for others, but in most implementations the interactionId is the best key to how the instance should be processed, and so was placed in the root element name

The schema don't support multiple domain model (payload) MTs.

• The XML ITS would have no problem with late-coupled interactions, and any number of wrapper / payload / cmets-with-exit points that the methodology comes up with. It is the current schemas that have not been designed to deal with that, and nor has the current v3 generator that builds the schemas for the ballot pack / normative edition...

The XML ITS just defines the set of valid instances for a V3 static model (interaction or document) -- it says nothing about what the schemas should look like. The XML ITS does not define the schemas to be used, and as such a problem with the schemas is not automatically a problem with the ITS. As long as the instances remain consistent, the schemas can be varied or not used at all.

• The ITS says what the elements and attributes in the instances must be called, and what they can contain (and gets this information from the HL7 definitions of the interaction/document). We have already identified three different schema styles that could be useful -- there is a trade-off between the different things that you may want to use the schemas for. The current distributed ones are designed for an uneasy combination of validation / code generation / documentation / PSVI decoration -- and regularly get criticised because they do not do one of these well -- the answer is to design and use schemas for the purpose that you need them, and to ensure that the distinction between the ITS and the schema design is maintained.
• The problem with late binding is that the names (and their sort position) are determined by what is bound. That's pretty hard to do in schemas. One of the core principles of the ITS is that you shouldn't be able to tell whether you're dealing with wrappers and CMETs or just a single model built from the ground up in one file. That means the names need to reflect the formal naming standards they would have if everything was all one model and the sort order needs to do the same.
  • If we move to a pure RIM schema where we don't attempt to enforce model constraints within the schemas then we'd have a way to manage elements that could have any name, any type and in varying positions within another element which can be bound at run-time.