Executive Summary

2.4Generally Recommended Package

The modest change suggested in Section 2.6.4 (adding business names to RBMs for viewing) is justified in its own right whatever course the ITS takes. A closer relationship between the RBM and its analysis model or the ‘real world’ will only help all implementers.
In addition, better data type constraints (Section 2.9.1) would make progress on a long outstanding work item for HL7.
Comparison of this package against the original NHS project goals:

Goal	Outcome
Efficient message processing	No change
Wire formats that are easily understandable to implementers	Improved documentation on RBMs will help understand any wire model
Supporting semantic interoperability	Improved documentation on RBMs will help with semantic interoperability
Message definitions that are easier to understand, have wider industry tool support and are more easily traceable from requirements	Improved documentation on RBMs will make message definitions easier to understand and trace to requirements. No change in regard to tooling support.
Consistent instance structures (where equivalent) across domains	No change
More stability in the wire format across message model releases	No Change.

3CEN 13606

The NHS Connecting for Health (and independently, a few of its vendors and regional stakeholders) is actively investigating potential adoption of the CEN 13606 standard. Some of the work performed in support of this investigation has led to the prospect of genuine technical harmonisation between CEN 13606 and HL7 V3. The NHS intends to further investigate these opportunities.

4Conclusion

The investigation is still proceeding, and a number of open avenues must still be explored. It is acknowledged (with regret) that examples of the impact of these proposals on message instances (which are the main target of change for the new ITS) are outstanding.
Next steps will include generating examples, investigating the use of RIM-based serialisation, the role of templateId and templates generally, and creating specific XUMs and investigating their selective use in association with the RIM-based serialisation. A potential testing activity is described below.

4.1Testing Activity

In order to take the sets of potential proposals forwards, and to be in a position to provide a concrete set of proposals at the next working meeting, we would like to discuss with MnM and INM a project to explore the range of options, and provide the evidence base that HL7 would need to move forwards upon any of them.
The project could take a small number of use cases related to the londitudinal patient record, and generate a set of instances to illustrate how those use cases would be met using a combination of different existing HL7 standard models, and the potential developments discussed in this docucument.
The objective is to experiment using a set of openly available models for common clinical concepts, exploring how conformance to such structures is best expressed in the communication of information that is intended for use at some later date by a clinician. It will be assumed that the sender would not be in a position to know when or why the data would be used in future (beyond being within the lifetime of the patient and for the purpose of direct patient care).
The CDA and Patient Care models would be used to provide (alternate?) underlying structures for the information.
Detailed structures for concepts such as body mass index and allergies would be expressed using the constraints defined by the NHS, commonly used concepts work, and/or the NIH/NCI Data Clinical Models project.
The use cases will also include the requirement to document conformance to (transient) local best practice for the encounter being reported.

1. Usability in detail

1. Learnability

1. Requirements Traceability

A key complaint of NHS implementers is that it is difficult to trace the relationship between requirements and the message implementation specification. Requirements may be expressed implicitly in

• 
  analysis models
  
• 
  contracts
  

or they may be found in existing domain models and other interoperability specifications

The V3 infrastructure has no explicit support for the traceability of requirements to models. Although HL7 has been encouraging the use of requirements analysis models since the inception of V3, few are published within the V3 standard.

This problem is exarcerbated by the fact the RIM attribute names are fixed as the abstract values of the RIM classes. These names usually do not map directly to domain concepts, they are too generic.

It has been suggested that using terms defined in the business analysis models for a message instance (rather than the RIM-based terms) would be easier to understand to domain experts and implementers and also easier to relate to local data models. The adoption of business terms could be a desirable feature of a new Implementable Model.

Note: Although V3 documentation does not state how this should be done, the current HL7 Model Interchange Format (MIF) does allow for modelers to assign Business Names to attributes. HL7 tools have not yet implemented this feature.

2. Message Structures

Another factor that makes designs harder to understand is that a number of design decisions are 'buried' in the current XML ITS instead of being explicit. For instance,

• 
  many data type properties are constrained out
  
• 
  some V3 datatype properties and class attributes are XML elements, and some are XML attributes
  

Most of these decisions are not documented or explained in the ballot; they are only implicit in the XML ITS documentation.
Also, the rationale for the decisions relating to how the structures are serialised is often not documented – and often not apparent either, nor does it follow wider industry practices (though these are hardly consistent).
Modelling to support constraining an instance to meet local business requirements is not yet supported (although work has been ongoing for many years to address this with HL7 Templates).

3. Level of Abstraction

One significant learnability challenge is related to the abstract (though detailed) nature of message design artefacts.

4. Wire formats that are easily understandable to implementers

XML that at least some humans need to read (see the CSW semantic processing contribution in Appendix B for example context) needs to be human-readable for the same reasons that terminologies need to have well-crafted linguistic expressions as well as formal identifiers of terms. In particular, users of terminologies, including information systems developers and integrators, are less likely to make mistakes concerning terminology usage and processing when the linguistic expressions of terms are well designed. Similarly, users of XML, including in particular information systems developers and integrators, are less likely to make mistakes concerning XML based processing when the XML is easy for a human to understand.

Human-readability was one of the key original design goals of XML; unfortunately some (many?) designers of XML-based data formats have forgotten this, and developed XML formats that are designed solely for machine processing. XML that is designed for machines to read is indeed very difficult for humans, however this is a defect of these specific XML designs, not of XML itself. Giving weight to readability has been criticized as being "just aesthetics", however the key concern is rather (cognitive) ergonomics; "working well" rather than just "looking nice".

5. Semantic reusability

In V2, the concept of a PID (Patient ID) segment was something that all implementers and domain experts understood and that everyone re-used when they designed new messages. V3 has two issues working against semantic reusability: multiple CMETs are in play to define the same conceptual object and the use of CMETs is complicated.

2.