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

[Guevara, A. <Ale...@uh...>]

Hey Bryan, thanks for your comments, I think they are very helpful. I'll try
to establish a question/answer type of communication here, like in a
conference call ;)

 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) ... 

2. Before continuing to the next point, this seems like a good place to note
that enhanced mode "accept acknowledgements" could be sent (as per the use
cases) by the HAPI/JMS Bridge. 

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) ... 

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 ?

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.

5. It looks like checking syntactical correctness before sending the "accept
ACK" (in enhanced mode) is optional. Instead of having the Bridge optionally
parse the message, how about handling this separately. We could have a class
called FormatConvertor that just reads messages from one Destination,
translates them to a different format, and publishes the new format to
another destination. Formats would include 1) traditionally encoded, 2) XML
encoded, 3) HAPI Message object, 4) DOM document. This way it would be
easily configurable, for example selectors could be used to convert only
those messages necessary for a certain purpose.   

6. While we're at it, we could have a similar class called ContentConvertor
(applicable to ObjectMessages that contain HAPI Message objects).  This one
would consume from one Destination and produce new HAPI messages to another
Destination.  The new messages would be derived in some way from the
original messages (e.g. by copying fields, valuing according to some
conditional logic).  This would be accomplished by implementing an abstract
method (e.g. "convert(ca.uhn.hl7v2.model.Message) :
ca.uhn.hl7v2.model.Message".  Maybe in a later phase we could have a UI that
creates these convert() methods by dragging and dropping or something.  

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)

As I mentioned before, I'm just starting to familiarize myself with JMS, so
please let me know if I'm off track. 

Bryan 

alex6

-----Original Message-----
From: Guevara, Alexei [mailto:Ale...@uh...]
Sent: October 3, 2002 11:53 AM
To: hl7...@li...
Subject: [HAPI-devel] [for review] use case for "Processing and forwarding
hl7 query me ssages"



alex6



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.






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.