Executive Summary

1.9Other changes

1.9.1Data Type property constraints

1.9.1.1Proposal

We propose that a syntax for making positive statements about the values of the data type properties be developed that rather than using a general predicate constraint language such as OCL.

1.9.1.2Discussion

We know that such a constraint language has been an outstanding HL7 work item for a long time. Using OCL (or xpath etc) is a problem because these are negative statements that do not help any processor create conformant instants.
So instead, we propose a positive constraint language. We propose that cADL – with a few minor adjustments – is extremely well suited for the task.
The tool that produces XUMs will be able to represent these constraints in the appropriate fashion inside the XUM (both as OCL and schematron).
Of course, some predicate constraints are not supported by this language, and we are not solving that problem.

1.9.1.3Benefits

Solves a significant part of a long-standing HL7 work item with respect to standardising a constraint expression formalism.
This supports local implementation profiling that may be validated automatically.

1.9.1.4Cost / Risk

Modellers will have to learn cADL – though it is not terribly difficult. There is a prospect of tooling integration through the Eclipse effort.

1.9.1.5Performance

Not sure.

1.9.1.6Usability

This will be a big improvement because constraints that are variably documented will be consistently and computably documented.

2Groups of Proposals

During this investigation, it became apparent that the relationship between proposals and objectives is not simple. Much depends on how the instances are being processed. Within the NHS National Programme for IT, a range of different ways for the instances to be processed have been described, and some of these are documented in Appendix B. In general, there are at least two ways to process V3 instances:

1. 
   Process the XML with no insight of the reference model semantics, using the element names from the models.
   
2. 
   Process based in RIM structural and clinical codes.
   

These general approaches are found outside the NHS program as well.
Of the smorgasbord of proposals presented above, some of which are mutually contradictory, we can pick different menus which create a package of change tailored to either general approach for V3 instances should be processed.

2.1A package for Specific Model Processing

For users that process a specific model as XML, without great reference to or interest in the underlying concepts, a specific form of XML is most suited to their needs, and the more customisation that can be performed, the better. We can prepare a package of changes that will suit these users:

2.2 XML UML Models (XUMs) (all)

2.3.1 XUMs are built automatically

2.3.2 Managing References

2.3.3 Infrastructure Root Attributes

2.3.4 “Flattening” Models

2.3.5 Using Business Names in the instance

2.3.7 Prohibiting Fixed and Default values in the instance

2.3.8 A XUM for each RBM

2.3.9 Mixing XUM level by model

In this package, a new ITS is provided that requires a little extra work for HL7 committees, some extra work in the tools to create a few new features, and enables implementers to customise the XML they must use to meet their use cases.

In this approach, there is not a single wire format for any interaction. In effect, V3 is a meta-standard for wire formats.
For any implementer prepared to invest the work, or use existing toolkits (javaSIG, eclipse, others), the differences in will be transparent, as long as definition is available, but these solutions will not suit all implementers. The implementation problems and the perception of a lack of a stable base and increased complexity due to the multiplicity of wire forms will continue to be a significant problem for HL7.
Comparison of this package against the original NHS project goals:

Goal	Outcome
Efficient message processing	For specific message processing, efficiency is improved For reference model based processing, efficiency is decreased and problematic
Wire formats that are easily understandable to implementers	A given wire format should be very understandable to domain users. Experience with wire formats will not be easily transferable to other interactions, or easy to relate directly to the V3 reference model
Supporting semantic interoperability	For specific semantic interoperability, this is an improvement For general semantic interoperability, this will make implementers do more work, but it is still possible
Message definitions that are easier to understand, have wider industry tool support and are more easily traceable from requirements	Message definitions will be easier to understand as they are normative and final and simpler Message definitions will have wider tool support due to UML and schema and the styles used Messages may be more easy to trace to requirements because of the use of business names
Consistent instance structures (where equivalent) across domains	There may be no consistency in message structures across domains, or even within domains. Consistency will be in the hands of the final implementer – our experience rather suggests that this will mean there won’t be any
More stability in the wire format across message model releases	There may be no consistency in message structures across message model releases, or even within domains. Consistency will be in the hands of the final implementer – our experience rather suggests that this will mean there won’t be any