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

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

Well it looks like we have some new ideas to talk about, that put us in good
shape for another conference call. Is Wednesday, October 16, a good date for
everybody ?

alex6


>-----Original Message-----
>From: Leslie Mann (2147) [mailto:lmann@TADH.COM] 
>Sent: Tuesday, October 08, 2002 10:22 PM
>To: hl7...@li...
>Cc: 'Tripp, Bryan'; Guevara, Alexei; hl7...@li...
>Subject: RE: [HAPI-devel] [for review] use case for 
>"Processing and forwar ding hl7 query me ssages"
>
>
>Hello all:
>
>I have added a few comments below. Keep in mind that I am 
>beginner at both HL7 and JMS!
>
>Leslie
>
>> -----Original Message-----
>> From:	Tripp, Bryan [SMTP:Bry...@uh...]
>> Sent:	Friday, October 04, 2002 11:57 AM
>> To:	Guevara, Alexei; hl7...@li...
>> Subject:	RE: [HAPI-devel] [for review] use case for 
>"Processing and
>> forwar ding hl7 query me ssages"
>> 
>> 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.
>	[Leslie Mann]  
>	Bryan, I read the above as implying a single replying 
>application. If that is true then I think the use case would 
>already handle this with only a topic and reply queue as 
>should there not be only a single HL7 responding application? 
>My knowledge of Hl7 is pretty rudimentary but would not any 
>messages in this problem class be addressed to a single 
>application and if multiple applications are being 
>queried/messaged, that multiple messages would be required by 
>the sending application, each of which would be handled as 
>above. I think the problem here is in trying to extend the HL7 
>model (which is point-to-point?) to pub-sub.
>
>> 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.
>	[Leslie Mann]  
>	Agreed.
>
>> 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.  
>	[Leslie Mann]  
>	Perhaps an outbound topic could handle both points 3 
>and 4.  Each bridge needing to manage unsolicted messages 
>would subscribe to the outbound topic and setup an appropriate 
>message selector.  Any JMS messages received would be put on 
>the outbound HL7 conection.  Applications needing a PTP reply 
>can have the JMSReplyTo point to a temporary queue setup by 
>the sending application and the bridge can send any HL7 
>responses back via the queue to the originating application. 
>This setup would simply be the inbound setup turned "upside down". 
>>  
>> 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.  
>	[Leslie Mann]  
>	Bryan, can you elaborate on what you mean by "one 
>Destination" to "another Destination"?  I'm fixated right now 
>only 2 pub-sub topic clouds, one for  "inbound" and another 
>for "outbound" JMS messages with temporary queues setup as 
>necessary for "direct to originator" replies and applications 
>that are sitting right on the "clouds".  I can now see having 
>the apps move back from the "clouds" and instead be connected 
>by a series of chained queues that would connect 
>FormatConvertors or ContentConvertors as needed to the topic 
>clouds.  This would allow each app to massage messages as 
>desired.  Are you thinking about having multiple inbound XML, 
>traditional, etc topics with conversions/formatting done at 
>source rather than at destination?
>
>> 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 organizatio
>


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.