You are here: Home Services & Applications NHS Interoperability Toolkit ITK Releases Release 1.1 to Release 2 Upgrade Summary

Release 1.1 to Release 2 Upgrade Summary

Middleware Applications

In summary, the requirements for accreditation as 'ITK Application' or 'ITK Middleware' are equivalent between ITK R1.1 and ITK R2. This is not to say that there is no new content in the ITK R2 architecture specifications.

However this is in the form of additional modules which can be accredited separately. Going forwards then the accreditation certificate will also enumerate which optional additional modules have been achieved – with this being important information to consider when selecting a solution.

HL7v2-based messages (ADT)

The HL7v2 (ADT) messages are unchanged between ITK R1.1 and ITK R2.

However on a technical level, the type of the distribution envelope's "payload" element has been corrected in ITK R2 to align with the intention that a payload is either an XML element (plus children), or text (for example, a base 64 encoded pipe-and-hat message body).

This change fixes an erroneous schema validation failure from ITK R1.1 pipe-and-hat ADT messages. Existing accreditations are unaffected.

Discharge Summary

A number of relatively minor modifications have been made to the CDA message specifications. These are intended to increase flexibility and to make it easier to add additional CDA document types in future:

  • The web service used has been renamed from 'Send Discharge Summary' to 'Send CDA Document'.
  • The CDA document definition has been re-factored using HL7 'templates'. The practical impact of this is that a number of template ids will need to be inserted into the message content.
  • In addition, in ITK R2 the CDA document schema definition has been tightened up. While this does not represent a change of intent, it does mean that new errors may be revealed in existing implementations.

More substantially, the new Addressing and Routing requirement module(s) are mandatory for ITK R2 Discharge Summary implementations. (By implication this means that the sender and receiver address elements of the Distribution Envelope must now be used).

These new addressing and routing requirements have been added in order to open up distribution of CDA documents over more complex topologies, and to provide confirmation of receipt via an acknowledgements framework.