RE: [HAPI-devel] [for review] use case for "Processing and forwar ding hl7 query me ssages"

[Tripp, B. <Bry...@uh...>]

Hi Alexei, 

We're making good progress.  Comments below ... 


1. Queries and "original mode" unsolicited messages require a response in
point-to-point fashion (see v2.4 section 2.13). Maybe we could handle this
by producing two JMS Messages pointing to the same content: 1) one goes to a
Queue, and has its JMSReplyTo set to a corresponding response Queue (so that
one and only one JMS client can respond); 2) the other copy goes to a Topic
so that the message is available to any number of non-replying clients. 

Sounds like a good idea, but at the same time I think it adds some
complexity to the hapi/jms component. What about having two kind of bridges,
one for queues and another for topics (they both will inherit from some base
bridge class). In this case the client will know what to expect from the
bridge, and the bridge responsabilities will be clearly defined.
In the case of the topic bridge, we can choose to send back to the client
only the first response, send all the responses back (over a defined period
of time) and create a compound HL7 message with all the received responses
over a period of time) 

<bryan> 
I see your point, it could be pretty confusing.  Another way to allow either
a Topic or Queue would be to have multiple constructors, for example: 

	JMSBridge(Queue inbound, Queue response) { ... }

	/** If singleReply, only the first response to a given message 
	 * is forwarded and others are discarded */
	JMSBridge(Topic inbound, Queue response, boolean singleReply) { ...
}

The nice thing about doing it this way is that we could potentially sneak in
other options (as additional constructors) without confusing too many
people: 

	/** Can't reply */
	JMSBridge(Topic inbound) { ... }

	/** Copies of msg go to inbound Topic and Queue.  The Queue copy 
	 * has its reply-to field set to the outbound Queue, so that only
one 
	 * client can reply. */
	JMSBridge(Topic inboundTopic, Queue inboundQueue, Queue response) {
... }

... who reads all the constructors anyway?  The reason I like the last
option is that it makes sure that only one client responds (rather than
quietly discarding some responses).  However I agree that it's too wierd to
be the only option.  

</bryan>

3. Enhanced mode "application acknowledgements" and "deferred" query
responses are sent in a new message exchange. I think it would be valid for
multiple systems to respond in these cases. Also, these responses might be
expected on a different socket than the point-to-point responses. Maybe we
could manage this by naming outbound Destinations after the receiving
application (MSH-5). In other words if you want to send a deferred response
to a query, you check the sending application (MSH-3) of the query, look up
the corresponding outbound Destination by name, and send the message there. 

Does this means than when a query is received, it is acknowledged first
(accept acknowledgement) and after, the real response is sent as a new
message, that the receiving party will have to ack) ... 

<bryan> yes </bryan>

I don't understand clearly the concept of "looking up outbound destinations
by name", is that part of the hl7 std. or is a way you propose to solve the
problem that we could have with the same query being answered by many
systems ?
(here again, we can use the concept of compound query responses, meaning
that the bridge will collect all the query responses received within a
certain period of time and will send them back the the client as a single
hl7 message) is this viable ?

<bryan> 
I was just looking for a nice way to handle cases where you want to send a
message to a particular system and you know that system's name.  The
"application acknowledgements" and "deferred responses" are an example.
They are separate message exchanges initiated by the original receiver -- I
think it's common for systems to expect new message exchanges on a different
port than responses, so you couldn't necessarily use the reply-to Queue.
Also, the new message exchange might happen much later (e.g. off-peak), so
it wouldn't necessarily be convenient to hold on to an object reference even
if you did want the reply-to Queue.  

About compounding responses from multiple clients ... I'm not sure what to
think about this ... a couple of questions for now: 

1) How do we know when all the responses have come back?  We could wait a
specified amount of time but the longer you wait the longer the remote
system waits, and you would have to wait pretty long to be sure that there
were no stragglers.    

2) There are a lot of different response message structures.  Is there a
general algorithm for finding which parts to compound? 

</bryan> 

4. In addition to the bridge, we need a way to for JMS clients to send
unsolicited messages to a Destination, allowing for a response. How about a
class (let's call it HL7Producer) that you would construct with a Topic, an
outbound Queue, and a reply Queue. It would have a method like this:
"sendAndRecieve(ca.uhn.hl7v2.model.Message) : Message" that would perform
the following steps: 1) create ObjectMessage, 2) fill in header parameters
with MSH values (like the bridge, but using the parsed Message object), 3)
send to Topic, 4) check the values of MSH-15 and MSH-16 and set JMSReplyTo
to the inbound Queue if needed, 5) send to outbound Queue as well, unless
MSH-15 and MSH-16 are valued "NE", 6) return the response if there is a
point-to-point style response expected, or null otherwise.  

yes, this is definitely needed and it is is missing. For the time being I
think your proposal is good. In the long term, we should probably refactor
the whole connection framework to be able to accommodate any type of
connection.

<bryan> Agreed.  </bryan>


kool, these ( 5,6) are very interesting features, that will make the
hapi/jms bridge very powerful ( it could be the beginnings of an interface
engine). And at the same time, they are not hard to implement, so yes, let's
bring it in!!! (at the hapi/jms level for the time being, we could make this
a general approach at the moment when we decide to refactor the connection
framework)

<bryan> Great, let's do it. </bryan>

Bryan 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.