Executive Summary

1.2Multiple XUMs and a normative XUM

1.2.1Proposal

Only one XUM per HL7 domain or one XUM for all HL7 domains (or one XUM for each message model?) should be declared to be normative within V3. See also Mixing XUM level by model (Section 2.3) and A RIM-level XUM only (Section 2.4).

1.2.2Discussion

Although it is understood that multiple XUMs (based on different levels of RBMs) are possible to describe different wire formats, the normative XUM is always assured to be correct and should support ‘global’ wire format interoperability for V3 applications.
If determined on a domain-by-domain basis, committees should decide whether it makes sense in their domain for the wire format to support generic (multi-domain) message processing approaches (in which case a schema based on the RIM-level or Clinical Statement Pattern-level XUM may be appropriate), or whether their domain is sufficiently isolated from other domains for the wire format to be maximally optimised for processing efficiency (in which case a schema based on an DIM-level XUM may be appropriate). Domain-specific decisions may introduce difficulties in ensuring that common concepts (e.g. CMETs) used across domains have common wire representations.
If one normative XUM is declared for all V3 domains (e.g. based on the RIM), the wire format will be consistent across domains, but may retain the ‘complex’ wire structures required to define concepts many layers below the RIM in detail.
It should be possible to transform automatically between XUMs at different levels in a ‘stack’ if that stack is comparable to the RBM hierarchy of RIM-DIM-CIM-LIM (Reference Information Model-Domain Information Model-Constrained Information Model-Localised Information Model). This theory needs to be tested.
Each of these serialisation levels corresponds to increasing local interoperability and decreasing global interoperability as the specificity of the model increases, and would allow the implementers to choose the balance between global and local that makes the most sense for their project.
Note that the idea of a XUM at each level only really becomes beneficial as some of the other proposals below for optimising XUMs by flattening etc are added, so that the more specific XUMs are also describing wire formats that are more specific (rather than simply the same structure that is more sparse).
Note also that serialising at the domain or RIM level will ensure that the same data is represented in the same fashion no matter what constraints have been applied to it (at least in theory). Research suggests that, in practice, things are a little more complicated, and that HL7 already has several incompatible ways of modeling the same concepts. This results in data representations that are different because the RIM-based modeling of the same concept is different.
Instances serialised in XUMs should be automatically transformable to the current XML ITS wire format, but this has yet to be proved.
Note: Any model may be used as a ‘template’. A DIM is a template on the RIM, etc. A template is any model referenced as a constraint on the model being serialised. The template may be referenced in the instance, or in a profile – note that a profile is also a model, so it can be serialised directly (although this would not be a normative serialisation).

1.2.3Benefit

Providing a XUM for every model from the RIM down will allow implementers to choose the level at which they implement. They can choose to implement at a very specific level as that makes entry to a small project less costly, or they can serialise at a higher level, perhaps up to the RIM, ensuring that a bigger initial investment is protected and leveraged.
Setting a single XUM for global interoperability allows implementers to make a simple choice for global interoperability

1.2.4Cost / Risk

Normalising XUMs increases the workload on each V3 domain committee (if the decision is made at the committee level and not globally by InM). Automatic transforms between XUMs and between XUMs and the current V3 XML wire format need to be tested.

1.2.5Performance

If implementers are able to choose the level they operate at, and do choose appropriately, then performance and usability will be enhanced. If implementers are unable to choose, or must implement at more than one level, then both performance and particularly usability will be impaired greatly.

1.2.6Usability

See under Benefits.

1.3Mixing XUM level by model

1.3.1Proposal

Given that there is one XUM per RBM from the RIM down, it would be possible for each model to specify at which level it is globally serialised.
Note that this proposal is an alternative to that described in Section 2.4.

1.3.2Discussion

This would allow HL7 to standardise a very specific XUM for administrative information, and a very general XUM for more clinical information.
One clear outcome of the investigations within the NHS is that some information – generally more administrative in nature, such as demographics or scheduling – is handled very specifically, and not persisted in any store, and that implementers usually process the instances based on very specific model information. In the more clinical areas, however, the information more often persists and is processed in a general context (i.e. without reference to a particular message model). More information from the approaches of different NHS vendors is in Appendix B.
Note however, the use of “generally” and “usually” in the previous paragraph, and also that interactions between applications will often use data from these different domains, for instance, scheduling an appointment and including a clinical summary, or providing a clinical report with demographics included.
So one possible solution to this is to allow a profile to specify which parts of which model would be serialised specifically and which would be serialised generally.
A problem with this is that model boundaries are not always maintained, so there is some inherent complexity. Nor have we experimented with XUM or wire forms for this concept yet.

1.3.3Benefits

Implementors have a standardised way for controlling which information is represented very specifically, and which is represented generically, in order to tailor the representation of the information to their needs

1.3.4Cost / Risk

This needs further investigation.

1.3.5Performance & Usability

See above for previous proposal