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

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

Hi Alexei, Everyone, 

I just re-read the acknowledgement modes in HL7 with JMS in mind and I have
some new thoughts. I just want to throw these out for comments -- if they
make sense maybe we can work them into the use cases. 

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. 

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

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 reponse if there is a
point-to-point style response expected, or null otherwise.  

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

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

Bryan 

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