Executive Summary

1.4A RIM level XUM only

1.4.1Proposal

In this scenario there is only one standard XUM, the XUM for the RIM and datatypes. Everything is serialised using this XUM. The XUM is not enhanced with flattening or name replacing.

1.4.2Discussion

This has been discussed on and off over the years, known as “RIM serialisation”.
The XUM for this will be published shortly on INM / MNM lists.
This proposal draws attention to the use of templateId, and we are considering its use at the present time.

1.4.3Benefits

This approach could be beneficial for the following reasons:

• 
  It serves generic processing well – fixed and default values are present in the instance, unless fixed in the RIM, and there is no distracting names, only RIM semantics
  
• 
  For processing models directly, RIM level semantics will still support fairly simple processing of the data, or it might be relatively easy to write parsers that add the model links as the instance is parsed.
  
• 
  There will be a smooth process for scaling up the implementation – there is no potential confusion due to changing names
  
• 
  This is a native expression of what is actually happening in V3
  
• 
  The instances will be very stable over the years. Investments in V3 messaging will be maintained over a longer period
  
• 
  There will only be one model+schema, and it will describe all the instances
  

1.4.4Cost / Risk

There are some potential problems with this proposal

• 
  Validation will require a custom tool. This is the biggest single reason that this approach was rejected in the first place. However we have come to recognise that schemas – and any other general XML validation tool – can only provide so much validation, and a specific open source validator is being prepared to make up for this
  
• 
  There are a number of models where the models add semantics via the clone name, both in CfH and in HL7. While this is a recognised error in the modelling, it is very difficult to prevent this, and these kind of errors will only be picked up if an implementer tried to work with the RIM serialisation. This is both a reason to go with a RIM serialisation and a reason not to.
  
• 
  Recognising which of a set of choices an XML element conforms to can be difficult – at least computationally time-consuming, and perhaps, in the case of poor models, impossible. These models should be refactored if it turns out that it matters, but more research is required before we fully understand this (this is definitely a problem for validation, but may not be for understanding).
  

1.4.5Performance

As is the case with several of these proposals, the question of whether this is better for performance depends on perspective. It appears, however, that the impact of this on performance is good for generic processing and relatively neutral for specific message processors – unless the last issue in the risks turns out to be unresolvable.

1.4.6Usability

This should significantly enhance usability by providing a single clearly defined method that all implementations should use for understanding the instances, one that is clearly and closely derived from the foundational concepts of V3.

1.5Secondary UML presentations

1.5.1Proposal

It should be possible to publish a secondary form of the XUM XMI format where all classes, associations and attributes are fully adorned with stereotypes from the XML profile for UML (see http://www.xmlmodeling.com).

1.5.2Discussion

These secondary representations should only be published as files in the processible directories of the publication structure. Their sole purpose is for use by tools that support the XML profile for UML.

1.5.3Benefits

Industry tools that support the XML profile for UML can make use of this variation.

1.5.4Cost / Risk

It is a minor load on the V3 tooling to publish this second variation, slightly increasing publication downloads.

1.5.5Performance

No impact.

1.5.6Usability

See under Benefits.

1.6Relationship to the current XML ITS

1.6.1Proposal

Adopt (after further development) the UML ITS as an alternative to the XML ITS (both being current).

1.6.2Discussion

INM invited this project to consider making the new ITS a replacement for the current XML ITS. We consider it premature to propose replacing the current XML ITS at this time, although this issue may be revisited once more implementation evidence is available.

1.6.3Benefits

Allows implementers to decide which approach is more appropriate to their needs.

1.6.4Cost / Risk

Requires HL7 to support two ways of doing the same thing (implementing V3 in XML).

1.6.5Performance

No impact.

1.6.6Usability

Choice is not going to help interoperability, but neither is changing everything already built against the current XML ITS. Testing is required.

1.7XUMs are built automatically

1.7.1Proposal

XUMs should be derived automatically from RIM-based models rather than manually modelled.

1.7.2Discussion

Generating a XUM automatically from an RBM requires that instead of manually introducing modelling ideas to the XUM, these same ideas must be introduced as annotations to the RBM.

1.7.3Benefits

We believe that there are significant advantages in automatically generating the XUMs from the RBMs. The single biggest advantage is the well known single source aspect – this will not allow the RBM and the XUM derived from it to become out of sync with one other.
This means that the focus of HL7 committees remains on the RBM, as it is now, and the downstream products are created automatically.

1.7.3.1Cost / Risk

This requires tooling to automatically construct UML pictorial representations. This is a cost rather than a risk (i.e. it can be done).
The biggest cost is that the RBMs must be appropriately annotated for implementation modelling. We believe that this disadvantage is compensated by the benefits of automatically generating the XUMs with the intention of accelerating V3 adoption. Specific annotations are suggested in Section 2.6.

1.7.3.2Performance

No impact.

1.7.3.3Usability

This should reduce the risk of error by eliminating manual modelling in the transformation between RBMs and XUMs.