Executive Summary

2.2A package for Generic Model Processing

For users that process models in a more generic XML sense, where the processing is based on the RIM, data types and terminological semantics, we can prepare a different package where the focus is on accurate representation of the core V3 concepts in XML:

2.2 XML UML Models (XUMs) (all)

2.3.1 XUMs are built automaticall

2.3.2 Managing References

.3.3 Infrastructure Root Attributes

2.3.6 Using Fixed and Default Values in Instances

2.3.11 A RIM level XUM only

In this package, a simplified XUM based directly on the RIM provides a single model upon which all implementations are based. All models are treated as constraint patterns on the underlying reference model.

All implementers are encouraged to work with the reference model semantics in mind, but specific message processing can be performed for all properly designed models without much increased cost compared to using the XML ITS.
The long-term outcome of this approach will be a more coherent approach to the whole development of HL7 models. Not only does this address a number of implementation issues, it also will force HL7 to addresses several poor modelling issues.
Comparison of this package against the original NHS project goals:

Goal	Outcome
Efficient message processing	For reference model processing, efficiency is improved For specific message based processing, efficiency is not decreased very much
Wire formats that are easily understandable to implementers	There is a single wire format based on the reference model. In order to understand the ire format, implementers will have to learn the reference model
Supporting semantic interoperability	This package is all about semantic interoperability. Semantic interoperability is improved by focusing on the reference model expressions and reducing the currently inconsistent contribution of the models
Message definitions that are easier to understand, have wider industry tool support and are more easily traceable from requirements	The message definition will be easier to understand as the visual model will relate directly to the instance The single XUM will have wider tool support due to UML and schema and the styles used. It is not clear what tools will be useful to help implementers relate the models to their implementation task
Consistent instance structures (where equivalent) across domains	There will be very high consistency across domains
More stability in the wire format across message model releases	There will be very high consistency across message model releases

More research is needed before making a final recommendation, particularly in these areas:

• 
  How many models are difficult (or impossible) to match back from the instance to the model clone classes?
  
• 
  Does it matter if there are any?
  
• 
  Can a solid validation tool be written that meets implementer requirements?
  
• 
  What tooling support should be provided to help implementers relate static models to their implementation tasks?
  
• 
  Is a slightly higher level reference model such as the clinical statement (or CDA) a possible alternative, and is this a good idea?
  

2.3Having your Cake and Eating it too?

It may be possible to combine these two packages into a single package that provides both features, and results in the best of both worlds, with a manageable cost.
In this package, HL7 publishes a single global XUM – the RIM based serialisation approach – and recommends its use for global interoperability. For global interoperability, this provides the benefits of the package described in section 3.3.
In addition, it is recognised that such a generic wire format may not suit all users in all domains, so users should be allowed to create their own profiles, and from these profiles generate their own XUMs which reflect their own implementation concerns. For these users, the benefits of the package in Section 3.1 will be manifest. Implementations based on these profile specific XUMs may claim a restricted conformance to HL7, rather than general conformance.
It will be possible for implementations to support both approaches transparently, if they invest the work to do so, or use some appropriate open source library should such exist (and there are plans to develop one).
This package meets the NHS project goals the best:

Goal	Outcome
Efficient message processing	Where highly efficient message processing is appropriate, it can be supported. Where generic message processing is appropriate it can be most efficiently supported
Wire formats that are easily understandable to implementers	Wire formats that are generic or specific - depending on the needs of the implementers – can be used
Supporting semantic interoperability	Semantic interoperability is improved in all cases
Message definitions that are easier to understand, have wider industry tool support and are more easily traceable from requirements	The message definition will be easier to understand as the visual model will relate directly to the instance, either using generic or specific messaging XUMs will have wider tool support due to UML and schema and the styles used. It is not clear what tools will be useful to help implementers relate the models to their implementation task at the global interoperability level. At the specific interoperability level, implementers will have tools to support their models
Consistent instance structures (where equivalent) across domains	There will be very high consistency across domains where desired
More stability in the wire format across message model releases	There will be very high consistency across message model releases

Of course, realising all the benefits as described here depends on whether it is possible to choose global or specific usage appropriately. This is a focus for ongoing investigations.