[HAPI-devel] JMS HL7 addressing mechansim

[Leslie M. (2147) <lm...@TA...>]

I've been thinking more about how the bridge could use message properties to
generate HL7 responses and have come up with a few ideas that seem
interesting. Below are some rough ideas about how the mechanism could work.

Based on my understanding that HL7 messages are point to point I see two
kinds of applications using JMS: "legacy" point to point apps and "JMS-Hapi"
apps that could be point to point, multicast, or broadcast. Examples: a
point to point app could be an order entry system to a lab system and a
broadcast app could be a distributed EHR system that needs to query all
connected systems (can't think of a multicast example). These could all be
supported with appropriate message properties, a response filter mechanism
in the bridge, a single JMS topic, and multiple bridge sessions with the
topic. Topic sessions would be JMS_Inbound (all HL7 messages received from a
HL7 source), JMS_Outbound (all HL7 messages selected from the JMS topic),
and multiple? JMS_HL7_Outbound (only HL7 response messages). Note that JMS
subscribers can use a "NoLocal" attribute to inhibit the delivery of
messages published by its own connection.

All inbound HL7 messages passing through a bridge would have the HL7
destination and the messaging mode (PTP, multicast, broadcast) set as some
of the message properties of the corresponding JMS message.  If a response
is expected, once the message has been successfully published to the
JMS-Hapi topic via the JMS_Inbound session the originating bridge will setup
a JMS_HL7_Outbound reply topic session with a selection of JMSCorrelationID
= JMSMessageID of the just sent message.

Any connected bridge would be able to retrieve the message via JMS message
selectors on it's JMS_Outbound session and pass it on to it's connected HL7
system.  If a reponse is generated by the connected HL7 system the bridge's
response filtering mechanism would determine whether an HL7 response should
be forwarded to the originating bridge: PTP - bridge's HL7 application and
facility must match message's destination application and facility,
multicast - bridges HL7 application must match message's destination
application, and broadcast - just forward all responses.  If the filtering
mechanism determines that a HL7 response is needed then the original
message's JMSMessageID would be entered into the reponse message's
JMSCorrelationID field otherwise the field will be left empty. All responses
are published to the JMS-Hapi topic via the JMS_Outbond session.  Again, any
bridge with an appropriate selector would be able to retrieve the response
message but the originating bridge's reply topic subscription,
JMS_HL7_Outbound, will receive only those messages destined for it's
connected HL7 application based on selection of matching JMSCOrrelationID's
and these response messages would then be the only ones sent out to the HL7
app.

Some advantages that I see for such a mechanism:
1)  The ability to query all connected systems, be they "legacy" or
"JMS-Hapi", without any knowledge of the HL7 system topology. I can simply
address my single JMS message as broadcast and then wait for a response from
all the connected systems that select and receive my message.  

2)  All messages, whether query or response, use a single topic and can be
selected by a connected bridge (if a query is of interest, may not the reply
be as well?)

Disadvantages:
1)  Need to have more complicated bridge to handle reply filter mechanism

Any comments?

Leslie