“Message routing”
HL7NL#803
CQ Proposal for HL7 Version 3 Ballot 8
- Version 1.2 –
Status : Final
Date : 20041025
Author : René Spronk, HL7 Netherlands,
The contents of this document have been placed in the public domain. Note that the images in this document are based on HL7 Artifacts, these are © HL7 Inc.
Content Page
1. Introduction 2
1.1. Message Routing 3
1.1.1. Unable to route 3
1.1.2. Communication problem Notification message 4
1.1.3. Reply To – Transmission Wrapper 4
Introduction
The IM ballot material describes the dynamic model used to exchange messages between 2 applications.
The current material doesn’t describe the issue of routing messages. Given that most healthcare provider institutions use one or more communication servers (message brokers) almost all messages are routed in one way or another. A number of countries are working on the creation of regional and or national networks for the exchange of messages between healthcare provider organizations. These infrastructures for the exchange of messages quite heavily depend on messages being routed.
This proposal describes a number of issues related to the routing of messages and proposes solutions for those issues. This proposal doesn’t attempt to cover all open issues related to the routing of messages.
The aim of this document is twofold:
1. To seek approval of the HL7 community that the way in which routing is described in this proposal fits with the principles of HL7 v3;
2. To propose a number of textual changes to the IM domains, to clarify the use of certain classes and attributes when messages are being routed.
Acknowledgements:The development of this document was financed by NICTIZ (www.nictiz.nl), the Dutch Institute for ICT in Healthcare.
Message Routing
NOTE: These proposals/implementation guidelines are for release 1, unless otherwise noted. They are meant to be compliant with the current dynamic HL7 models.The transmission wrapper contains data which identifies the sending and receiving applications. An application that receives a message always should check if the message was intended for that specific application.
Note: a message can currently still have multiple receivers, each identified by a different Device.id. Multicast messages have not been considered when creating this proposal. If and when it is decided to continue with the support of multicast messages routing will need to be addressed in a future proposal.
(proposal statement #803.1:) The destination as listed in the transmission wrapper (i.e. the Device.id of the receiver) identifies the (ultimate) destination application. Any routing applications won’t be identified in the transmission wrapper. (CQ WGM 2004-09-29. proposal statement accepted)
(proposal statement #803.2:) If the transmission wrapper indicates another receiver than the application that has received the message, then the receiving application has to make an attempt to forward the message towards its final destination without processing the message itself. The message may be forwarded directly to its destination, or to yet another routing application. If the message can’t be forwarded this can be reported in an acknowledgement message (using 806 proposal terminology: an accept rejection) (also see next paragraph). (CQ WGM 2004-09-29, discussed, tabled until taken off the table again)
Discussion in Atlanta, Sept 2004, related to 803.2:Re proposal 2: Mark outlined a scenario where a message is routed to another besides the initial intended receiver. Gaby says in that case the message had better be rewritten; if someone mistakenly sends her a message she need not send it back, why should she be forced to forward it. The phrase “should forward” would be better than “has to make an attempt to forward”. Paul B infers that sniffing is OK, but processing is not. Gaby has a use case for augmenting the message. Mark asks if what we are clarifying is HL7’s position on lurking; René confers that it is, and that the position is that it is unacceptable for a non-intended receiver to process a message in any way whatever. Tomorrow a process for explicitly identifying lurkers will be discussed.
Miroslav points out that sometimes that there are broadcast use cases that involve augmentation. Paul B doesn’t understand how a message can be addressed to a lurker (sniffer). Mike asks if we are talking about cc:/bcc:? Miroslav says no, we are talking about to:, but there might be multiple machines between from: and to:. He feels that intermediate routers should change none of the message, even the wrappers.
Mark asks about the ADT system that is announcing admissions to the rest of the hospital. All receivers have various responsibilities. The ADT system doesn’t care who receives the message. This Mark perceives as a huge problem with application roles – that the contractual responsibilities in the receiver must be embedded in the interactionID. Darius asks – what if there are both V3 and V2 recipients? Must the sender generate 2 messages? Can’t the engine handle it?
René states that listening in for unintended purposes is not permitted by V3 – although this concept will be discussed tomorrow. Paul B disagrees: he thinks that because the lurker does not claim conformance to any application role, it is not bound by conformance constraints.
Andrew suggests we may need a new motion.
(proposal statement #803.3:) A routing application shall not modify the control act nor the payload of the message.
(proposal statement #803.4:) A routing application shall not change the identification of the sending or receiving application, organization or the classes related thereto.
Unable to route
Figure 1: Interaction diagram related to message routing
A message routing example: Application B receives a message. The message lists application C as its receiver. B detects that the message is intended for C. B doesn’t process the contents of the message. There are 3 subsequent scenarios:
· B knows how to route the message to C. In this case B sends an accept ack (OK) to A to indicate the successful delivery of the message. B sends the message to C. C detects that the message is intended for C; and processes the contents of the message. C sends an accept ack to B to indicate the successful delivery of the message.
· B knows how to route the message to C. The link from B to C is however temporarily unavailable. In this case B sends an accept ack (OK) to A to indicate that the message has been successfully delivered to B. The accept ack contains the following attributes: Acknowledgement.typeCode = ‘CA’ (Accept), AcknowledgementDetail.typeCode = ‘W’ (Warning), AcknowledgementDetail.code = ‘RTWDEST’ (Routing warning, routing destination temporarily unavailable).
· B doesn’t know about a system C, or isn’t able to route messages to C. In this case B sends an accept ack (ERROR) to A to indicate that the message could not be routed. The accept ack contains the following attributes: Acknowledgement.typeCode = ‘CE’ (Error), AcknowledgementDetail.typeCode = ‘E’ (Error), AcknowledgementDetail.code = ‘RTUDEST’ (Routing error, unknown routing destination).
(proposal statement #803.5:) If an application receives a message for routing, but it is unable to route it, it will indicate this to the sending system (i.e. the original sending application and the previous routing application) in the accept acknowledgement (in proposal 806 terminology: the accept refection) (in case an accept ack was requested by the sending system by means of the Message.acceptAckCode attribute).
(proposal statement #803.6:) Accept acknowledgements (if used) are exchanged between 2 applications (a router being an application), they are not end-to-end. PROPOSAL WITHDRAWN. Proposal 806 covers this issue in a different way (the “commit ack”).
(proposal statement #803.7) If a sending application wants to make sure that a message routed via intermediary applications reaches its final destination it will have to use an interaction that results in an application response (e.g. application ack, query response). Application responses are end-to-end.
Reply To – Transmission Wrapper (ACCEPTED AT WGM MAY 2004)
Figure 2: Transmission Wrapper (Partially shown)
(In previous ballots there have been comments related to RespondTo. The underlying use-case was unknown)
One of the use-cases one can think of is related to “prefetching”. This scenario is in analogy with DICOM prefeteching, i.e. where all existing images are moved to the correct viewing workstation on the night before a patient has an appointment for an imaging procedure.
In HL7 terms: querying for information (e.g. by a scheduling system), whilst sending the results to another application.
(proposal statement #803.8, for release 2 of IM:) The use of RespondTo can be compared to that of Receiver and/or Sender.
In Ballot 7, RespondTo is associated with a class of classCode ENT. One of the specializations of classCode ENT is classCode DEV (device).
(proposal statement #803.9, for release 2 of IM) The generic EntityRsp class (classCode ENT) will be specialized into the Device class (classCode DEV, the Device class is already present in the DMIM). [See Figure 2]. This change will result in a more consistent transmission wrapper.
10/25/2004 2