Executive Summary

Background

The NHS National Programme for IT experience to date identified the following business issues related to HL7 V3 usability, mostly concerned with learnability, efficiency and satisfaction:

• 
  It takes many months to become proficient in implementing V3 designs and consequently the skills pool of skilled designers and application developers is limited
  
• 
  Larger-than-anticipated message sizes for routine transactions are making service level agreements challenging for the national transaction messaging service
  
• 
  The message instances carry a high proportion of V3 model-related data which is sometimes perceived as unnecessary (e.g. is not used in semantic processing at either end of an exchange) while obstructing their human-readability and ease of validation and debugging
  
• 
  The deeply-nested structure and relatively abstract element names in message instances make them seem more complicated in some cases than real world problems call for (e.g. simple administrative messages become ‘bloated’ with RIM semantics); this can also make it more difficult for humans to find 'payload' data in order to map it to local data stores or to the message's original business requirements
  
• 
  Each XML element carries both implicit and explicit processing requirements
  
• 
  Current V3 schemas do not support code generation well, and also do not support any reusability of the generated code
  
• 
  Current V3 message models do not fully support local implementation requirements, such as the need to re-use parts of instances and to have mechanisms for easy-to-find and understand constraints on data
  
• 
  Informal observation to date seems to suggest that many vendors do not generally find V3 technically attractive, and some have indicated that they would adopt it only if specifically paid to do so. It would be useful if V3 was more generally or obviously perceived as making implementers jobs easier, not more difficult. Even for those suppliers who see the benefits of committing to V3 with its prospect of wider interoperability, an HL7- endorsed improvement would significantly ease the uptake of the standard, and thus the return on investment to all V3 stakeholders.
  

In addition, the NHS would like V3 message representations to have wider industry tool support, stability in the wire format and assurance that semantic interoperability is maintained.

More discussion related to usability issues may be found in Appendix A.

1. Objectives

The objectives for the NHS-sponsored investigation into a potential new HL7 V3 ITS were to explore improvements in:

• 
  Efficient message processing (particularly with validation against constraints, possibly also in semantic processing)
  
• 
  Designs that are proven to support a defined level of semantic interoperability across heterogeneous applications
  
• 
  Wire formats that are easily understandable to implementers (and easier to map to local data stores)
  
• 
  Message representations that are easier to understand by implementers, have wider industry tool support and are more easily traceable to and from real world implementation concepts and business requirements
  
• 
  Consistent instance structures (where equivalent) across domains
  
• 
  More stability in the wire format across message model releases
  

2. Design Principles

The following are this project's working design principles:

• 
  Support patient safety in the accuracy and consistency of clinical message interpretation
  
• 
  Support the traceability of business requirements through message design and implementation
  
• 
  Support overall messaging performance improvements (e.g. within the NHS environment), with the understanding that gains at one end of an exchange sometimes translate into costs at the other
  
• 
  Increase the ease of validating and de-bugging messages
  
• 
  Enable the exchange of data using XML in an HL7 V3 standard way
  
• 
  Enable the use of code-generation tools from message representations (e.g. UML-based tools)
  

In addition, these features are considered to be desirable in a new V3 ITS:

• 
  Support the wider use of off-the-shelf XML tools
  
• 
  Reduce the training time required for message developers and implementers
  
• 
  Support use in a hybrid environment with the current XML format
  
• 
  If possible, for both European regulatory reasons and implementation desirability, relate to CEN 13606 archetypes implementation
  

2. XML UML Models (XUMs)

It is proposed that a new ‘implementation model’ is introduced, to act as a formal statement of what must be implemented, derived from a RIM-based model.
This new implementation model will be described as both a UML class diagram and an XML schema. These models, in the context of this report, use the acronym XUM (pronounced ‘zoom’, for XML UML Model).
This section contains a series of proposals describing the base concept and form of a XUM. The XUM is built by automatically transforming an RBM, using new annotated information on the RBM that helps optimise the XUM for implementers.
Some of the details described in this section need to be further explored and tested. A few inconsistencies in ideas proposed still need to be addressed.

1.1XUMs in concept

1.1.1Proposal

A XUM is a model that describes, as both a UML class diagram and an XML schema, an implementable form of a V3 instance based upon an RBM. The XUM describes a particular wire format, but is also useful in terms of commercial tools use and ease of implementer understanding. The UML and XML forms of the XUM should be as isomorphic as possible.
Concepts

The XUM consists of a set of definitions of classes with attributes and associations, along with associated implementation constraints and enumerations. The names of the classes, attributes and associations should be suitable for use throughout the implementation path.

The XUM will use an enumeration for structural codesets defined by HL7 which are not subject to external extension, are carried by the type CS and are mandatory in the HL7 models,
There will be base HL7 reference XUMs as implementation models of the HL7 datatypes and the structural vocabulary domains as enumerations.
The XUMs will have the same model boundaries as the RBMs (i.e. CMETs etc).
The XUM will contain processible annotations that will allow processors to rebuild a valid RIM instance from the XUM-based instance and the XUM. This is the intent, although the feasibility and specifics need to be further investigated.
UML

Each XUM is represented by a single UML class diagram with a single UML package. The UML representation of the XUM may use the following UML constructs:

• 
  Classes with Attributes. Operations are not supported since these are representations of wire formats with no behavior.
  
• 
  Parameterized classes with one class parameter. All parameterized classes are collections
  
• 
  Constraints using OCL in notations attached to the class.
  
• 
  Constraints must include the context
  
• 
  Generalization associations
  
• 
  Named composition associations (represented as by value in XML)
  
• 
  Named associations (represented as by reference in XML)
  
• 
  The {xor} notation (? For discussion)
  
• 
  The stereotype <> for enumerations
  
• 
  The stereotype <> for marking entry points.
  
• 
  The inbuilt types from the OCL 2 kernel, or any types found in other XUMs which must be explicity accessed as UML packages
  
• 
  Comments in attached Notations.
  

The UML representation will be published as a GIF image, and SVG picture, and an XMI file.

XML

Each XUM is represented by a single XML schema. The schema representation of the XUM may use the following constructs:

• 
  Complex Types
  
• 
  Element and attribute definitions
  
• 
  Global elements for entry points
  
• 
  Simple Types for enumerations
  
• 
  Sequences
  
• 
  Choices for choices
  
• 
  Schematron rules for constraints
  
• 
  The inbuilt types from the schema standard, or any types found in other XUMs which must be explicity imported as schemas
  
• 
  Comments in AppInfo annotations
  

The schema representation will be published as an xsd file. All the schemas will be in the same namespace.

Relationship between XML and UML

The UML diagram and the XML schema will be as isomorphic as possible. Other than in the constraints, the two representations should be equivalent. There will be simple rules for describing which UML attributes are represented as XML attributes, and which UML attributes are represented as XML elements.

1.1.2Benefit

The provision of the two closely-related forms (UML and XML schema) will make the implementer’s task considerably easier. In particular, this arrangement is intended to allow model-driven development of V3 artifacts with due concern for allowing the re-use of model-based generated code. In contrast to the current XML ITS (which includes a number of idiosyncratic algorithms applied between the RBM and its wire format), the XUM makes the model-to-schema transformation more transparent.

In addition, the XUM rests on a set of datatypes that are much easier to implement than the XML ITS data types, which should ease implementation concerns considerably. (Note: This depends on the success of a data types change proposal currently in progress in INM.)

As a consequence of only using the commonly accepted features of UML and XSD, it will be easy for implementers to take these models and implement them in their products

1.1.3Cost / Risk

This approach introduces a new type of model to the V3 development and implementation process.
A considerable portion of the risk and cost is bound up with the question, who generates this model? This is discussed in Section 2.2. The rest of this cost / risk analysis focuses on the technical aspects of the XUM.
There is a risk that introducing an implementation focused XMI file will require HL7 tooling and INM to re-examine the lack of XMI support in current V3 modeling tools.
There is a risk that the presence of the new layer of modeling may add to the learning curve of the V3 implementers. If this happens, the whole approach has failed, as the explicit intent of this model is to make implementers lives easier by giving them the information (in model form) for exactly what they want and need.
There will be a tooling and publishing cost of this new model however it is created.
INM will have to maintain the new ITS and its associated reference XUM(s).

1.1.4Usability

The explicit intent of this proposal is to improve usability by providing implementers with the model information they want, including allowing them to choose UML or XSD, and still be able to transform automatically to equivalent RBMs.

1.1.5Performance

In general, the introduction of the XUM is not expected to have significant impact on performance in its own right. There is a possibility that the wider tooling support it allows will introduce improvements in performance in a general sense, and also a possibility that some particular aspects of the implementations that result from the XUM will be slower than with the XML ITS. This requires further investigation and experimentation.

1.1.6Example XUMs

A new data types summary XUM:

Simple supporting data types XUM:


An RMIM-based XUM example is planned, but not yet available.

1.1.7Further discussion

The XUM will not support the schema or UML validation of HL7 Templates. Specific software solutions will be required for this. (This is also a limitation of the current XML ITS.)