UML ITS

The UML ITS (Release 2 thereof) is a proposal by NHS CfH to ease the implementation burden for v3 artefacts. This is achieved by simplifying the on-the-wire format as well as using UML based models which can be used for code generation. Note that the proposal has not yet met the ITS Acceptance Factors.

The intent of this page is to give a high level overview of the proposed new UML ITS. Considerations, open questions, and comparisons with other approaches won't be described in any detail. See the UML ITS Proposal v0.6 for a status report on the project that is driving the UML ITS.

Summary

The UML ITS has 2 parts.

• a technical infrastructure for making wire formats easier to implement. See UML ITS technical
• transformations applied to the V3 concepts from RBM to wire format to most suit implementors. See UML ITS Policy

The technical infrastructure applies whichever transformations are chosen to assist the implementers.

History

The UML ITS is a non-linear development of the existing UML Object Definition, and solves a number of problems that were identified in the first release that prevent either further linear development, or implementation.

The work for the UML ITS is being sponsored by the UK CfH in the hope that the UML ITS can address a number of the implementation issues that the NHS has identified.

Other stuff

All the rest of the content of this page is to be moved to one of the 2 links above.

The Goal of the new ITS is to be able to go to an implementer and offer them a "thing" they can use, an implementable model. The implementable models (the product of the transformation described by the ITS in the form of UML + schema) will be normative. The new ITS will include explicit transformations to address implementation concerns, e.g. to use an on the wire format that is as minimalistic as possible. The output of the ITS can be used for cde generation.

RBM <---> XUM Implementable Models (UML diagram <-> Schema)

The UML ITS transforms a HL7 model to a a XUM (the implementable model, expressed both in terms of an implementable UML model as well as an implementable schema) and then to a message. The XUM works with the commonly used tools, and it correctly specifies the wire format. It doesn't completely describe the validation rules for the message, no schema or UML model will be able to do that, because the HL7 models rely heavily on terminology. A XUM consists of a pair of schemas and UML diagrams that specify the exact same wire format, implementers can code generate from them and exchange data. WYSIWYG: What you see in the schema or in the diagram, is exactly what goes on the wire.

There is existing work outside HL7 on the question of transforming from UML diagrams to an XML instance or a schema. The UML ITS is intended to leverage this work (One of the existing issues is that UML to XSD transform requires sequencing of the associations, which is a "bit of magic", but does need to be represented explicitly.

The transformations that applied during the process from the RBMs to the wire format are done before we create the implementable model, so these transforms are made explicit, and there is no surprises for the implementer. The transformation from RBM to XUM is deterministic, so it will be possible to go back from UML to the RBM.

The transformation between the RBM and the implementable model could include optimizations of the model in order to address implementation concerns, e.g.

• Sending of fixed and default values, especially structural codes.
• Flatten RIM constructs, e.g. telescope attributes of an associated class into other class,
• Add business (or: local) names. e.g. for "effectoveTime"

These issues are discussed in optimising wire formats for users

The new UML ITS creates a model that only contains that which is needed on the wire. It contains less XML elements than the XML ITS. I doesn't follow RIM gramatical structure/grammar, they are not needed on the wire. This approach is possible because you can go back from the implementable model to the RBM.

Code generation based on flattened (UML-) implementable model.

Serialization Details

Which RBM do we use (RIM, DMIM, RMIM, MT, template?) for serialization. Same concept at every point. XML ITS uses MT. DMIM may be best level. fits best with SOA services model. There are arguments for RIM based serialization without using local names. Lots of different names makes implementation more difficult, e.g. dozens of xPaths to identify things in similar model, more need for documentation. If one chooses RIM, then all other models become "templates". Raises issue of assigning semantics to clone names again, many current models aren't deterministic.

Reading the instance with the definition. Need to consult the definition on order to understand the instance.

The relationship between the instance and the meaning indeterminant in the absence of the model.

• RIM based, no need for any definition;
• full fledged RBM-based serialization including all structured codes, no need for definition;
• RBM-based serialization without structured codes, need to consult definition - current positition

Related

The proposal has associated proposals for related issues (that are not purely ITS-related, but are a prerequisite for the ITS to work). These are:

• Datypes R2 Isues
• nullFlavor cleanup. Cascading of associations which lead up to a class with an important attribute. Can be dealt with by making everyting mandatory BTW.
• templateId
• (general approach) Could be RBM -> Flattened Model -> apply any ITS
• (XML ITS) create normative schema?
• Sutructured attribute. Currently no need to be on the wire - requires that receiver has to know model in order to process the message. Generic processing requires that one knows the struc codes (e.g. Java SIG code), looking them up carries implementation /performance overhead. Want to have everything in the instance. Discussion in MnM.