Executive Summary

Efficiency

The existing instances are a direct representation of the RMIM. This is a core principle of the XML ITS, but it interferes with some aspects related to ease of implementation. In addition to expanding the message size, the RIM structures, which represent the Act-Relationship-Participation-Entity grammar structure, are unwieldy when it comes to representing the instances. It leads to the introduction of XML elements that have no direct counterpart in the 'real world'. Each element introduces more work and uncertainty for the implementers, especially as each element may carry the infrastructure root attributes.

In addition, the RIM grammar model is primarily relevant at the design stage. During the actual task of processing the data – where the RIM mappings are sometimes not used in local context – any extra nested elements and their associated attributes (real or potential) are a waste of resources (processing time, programming etc).

The XML ITS also has some complexities. The datatypes have very clever subtleties that make for great XML but make implementations harder than they might otherwise be, as they require hand programming to account for their complexities. In addition, the way that model boundaries are hidden in the XML ITS is clever and allows the designer extra freedom, but it is not good for implementers, as there is no solid model boundary points for them to rely on.

The real price of the way the XML works is the absence of a final authoritative definition of the model in terms of XML. The schemas should do this, but we have shied away from making them normative because the XML format is more important than the presence of a reliable model to describe the XML.

3. Satisfaction

   1. Industry tool support

In addition to impacting learnability, the use of an HL7-specific model representation formalism excludes the use of tools with wide industry support. This has led towards the requirement for customised tools, which, when weakly supported, has had a negative effect on ease of use.

For this reason, one of the design principles of this project is to investigate the use of UML and XSD to represent message implementation models.

Note: It is currently difficult to understand what it is about the current XML ITS that makes current tools 'blow up' when HL7 schemas are loaded. What is it about current HL7 schemas that prevents the generation of java classes from it? Is it too complex in terms of depth, size, possible recursions (including infinite), not enough constraints, too many 'includes'? Is the issue related to a UML tools requirement to be element-centric while V3's current approach is to rely on structural attributes rather than tagnames for semantic processing?

2. Wire format stability

The names of the associations in the XML ITS are very unstable. This problem has two parts. The first is that the XML ITS includes the model's association names in order to allow for schema based validation. As the model names change, so does the instance.

The second part of this problem is that these model names are prone to unpredictable change. The HL7 Visio RMIM Designer tool names associations itself, and numbers these in order to assure they are uniquely named. During model editing, the numbers change as the tool strives to keep the names unique. This has the effect that associations become renamed (e.g. pertinentInformation1 to pertinentInformation2) in different releases of the same model. It is even common for associations to exchange names (e.g. pertinentInformation1 becomes pertinentInformation2 and vice versa). It would be useful if the model design tool did not renumber association names when a new one is added. This has an effect on the schema and message instances (as well as the code to generate them) as the ordering is based on the full name with numbering. This also has an affect on message processing.

For example, when NHS pharmacy messages are digitally signed, the prescription response downloaded by the pharmacy gets constructed from the signed prescription uploaded by the prescriber. The response must therefore have the same content model as the prescription so as not to invalidate the digital signature. This means that associations must be named the same in multiple message models in a given release (as message chunks are physically shared in different message types), and it is also helpful if they do not change from release to release. It might be useful to have a tool to clone names from message to message, based on some kind of pattern/template that is derived from the business model.

Name changes also affect model design work in terms of model documentation. The current tabular view editor is not good at handling elements that are renamed and so a lot of cut-and-paste can be needed as names shift and change.

Model developers try to work around this and move things around so the names are preserved as much as possible, but this is imperfect. An unofficial NHS tool change is in use that allows manually forcing the numbering. This may alleviate the problem to a large degree. Also, editing tabular views (model annotation) may no longer be an issue (requiring manual intervention) with an upcoming MIF-based toolset.

Current tooling and methods do not support giving associations helpful names. The idea is that the structural codes and codes in classes at the end of the association provide enough information to process the model without needing to use the association names. It has sometimes been the case that modellers do not always give thought to the parseability of the message and so may neglect putting enough information into structural codes (and act.code, etc.) to enable processing without relying on element names.

Small changes can have relatively large effects on the output models if care is not taken. Element name-based parsing systems need updating with each release.

An additional effect of this arrangement is that presentations of data that are consistent with a single domain model, but subject to different constraints, will result in different wire formats, and therefore transforms are needed to convert from one instance to the other, even though instances may otherwise be identical.

Unless the message is being processed in a generic fashion, each variation will have to be supported with new software code. If fixed attributes are dropped from the message instance, generic processing is likely not possible.

In addition, as V3 does not yet support the re-use of 'constraint patterns' (only unconstrained CMETs) across models, this problem is exacerbated.

Applications should be designed to decouple serialization / deserialization from the underlying object or data model so they can deal with re-naming if necessary. Frequent name changes, however, still make parsing different versions of the same message unnecessarily complicated and it is sensible to retain path names where possible.

Note: A technique taking elements "off the shelf" while modelling would help consistency. This may, however, move the problem into "pattern-space", with the potential for creating conflicting patterns/templates. This may be addressed by using CMETs more, but how they are constrained would need to be resolved.

Another issue here is that the RIM-based and automatic naming give a degree of consistency in models as element names. Modellers are not constrained in naming classes, and this is a double-edged sword. Allowing individual expression in names quickly leads towards a tendency to view names as having meaning (instead of relying on structural codes to derive meaning) and so there is a natural tendency for implementers to want to rely on names. (e.g. the NHS Message Implementation Manual has been required to retain existing association end names between versions and to name associations consistently across different messages). If implementers rely on names, they are trapped when names change, partly through tooling flaws. If, however, naming choice was extended down to the attribute level, there is a danger that the number of names for the same thing will increase rather than decrease.

3. Semantic interoperability

Some of the implementation issues being encountered by the NHS with V3 are simply because V3 specifications are not implementation-tested prior to being 'finalised'. As there are no reference applications for semantic processing, it is difficult to judge how well (or to what level) current V3 designs support 'semantic interoperability' (or even, at times, exactly how they are supposed to do this).

Also, as the V3 design intent has been to support 'global' semantic interoperability 'as much as possible' (while acknowledging that full international semantic interoperability is not possible), the emphasis on the standard's designs has been to support the 'global' messaging case. It might be useful at this time to challenge this general orientation to V3 design, as the case for 'global' messages is probably at best marginal (in terms of instances) compared to the local case. This may be particularly important to do, as the use of 'global designs' has not so far improved the prospect for a broadly available skills pool of designers. Global designs have also not been tested or implemented as such to date. It is recognised, however, that vendors with multi-national markets want engines that can work to some degree 'globally'.

It is also important to improve the documentation for the 'global' case - i.e. real use cases need to be defined so that designs can be evaluated against requirements.

"Consumability" or "parseability" of message designs should be tested before release. Many designers have never been 'on the other side of the fence' and have not worked from HL7 specifications themselves. On the other hand, "parseability" would ideally 'come free' if the basic methodology is strong and easy to follow.

2.