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

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

Bryan/All:

I have outlined some more ideas about getting a single response out of
the messaging cloud and still stick basically to the Use Case.

Anyone see any problems with either the JMS or HL7?

Leslie

> -----Original Message-----
> From:	Tripp, Bryan [SMTP:Bry...@uh...]
> Sent:	9-Oct-02 12:20
> To:	'Leslie Mann (2147)'; 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"
> 
> 
	....

> Exactly, HL7 is pretty silent on pub-sub.  If we send a message to a Topic
> we're outside the bounds of HL7, since it no longer has a single
> destination.
	[Leslie Mann (2147)]  I have to disagree here. The JMS topic message
may
	have many destinations but I think the HL7 message payload itself
only has 
	a single destination.  See below for elaboration...
>   Any number of clients can grab it and if its reply-to is set,
> any number of clients can reply.  This might confuse the HL7 applications
> to
> which we connect, although they would probably just quietly log an error.
> HL7 doesn't allow us to address a message to multiple receiving
> applications
> either.  
	[Leslie Mann (2147)]  
	Okay, so if we agree that HL7 can only be addressed to a 
	single recipient, this recipient being identified in the JMS HL7
payload, does
	it also not mean that a well behaved HL7 application will only reply
to a 
	HL7 message that is addressed directly to it.  Assuming that our
listening
	environment consists entirely of well-behaved HL7 apps (since we
have HAPIly
	built them all :)) then there can never be more than one response
even if
	many are able to listen via JMS.  Not having any HL7 experience, why
do you
	think that "any number of clients" can (will?) reply?

	To prevent ill-behaved apps from actually doing that can we not
build a
	mechanism into the the bridge reply system which would only allow a
reply
	allowed by HL7 rules. So far our discussions have focused
exclusively on
	sending to a particular app. How about forgetting that, we just let
the inbound
	bridge fire the JMS message into the MOM messaging topic cloud
exactly as
	outlined in the Use Case. Any subscribed listener could then read
the message.
	The important thing then becomes having the correct outbound bridge
recognize
	that it's listening client is the only one that must respond.

	For example each bridge could be assigned an identifier 
	corresponding to the MSH-5 receiving application and MSH-6 receiving
faciltity
	(and whatever the equivalents are in the transmitting scenario or
whatever would 
	be suitable HL7 wise for this purpose).  When the bridge receives a
outbound
	JMS message it would compare the receiving application and facility
of the HL7
	payload message to its configured identity (perhaps they could be
added to the
	JMS message properties to avoid having to parse the HL7 payload).
If there is
	a match the outbound bridge would connect to the reply queue setup
by the
	inbound bridge ,put the message on its outbound HL7 connection and
wait for
	a reply which it would then put on the reply queue back to the
originating bridge.
	If there was no match it would simply forward the message on to its
outbound
	HL7 app and ignore any replies from its connected app.  This should
result in
	only a single response being generated from the messaging cloud.

> > 	[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". 
> 
> If I understand correctly you're suggesting a Topic where I suggested a
> Queue?  This seems reasonable.  The advantage is that we can route
> outbound
> messages all over the place.  The downside is that we run into the same
> problem with what to do if multiple JMS clients try to respond.  
> 
> Actually, on second thought I might disagree with you.  Within JMS a
> message
> could pass through any number of topics for  routing and conversion.
> However we should make it possible to send a message specifically to a
> particular destination.  For example let's say someone wants to route a
> message from system A to system B.  If the system A bridge publishes to a
> Topic and the system B bridge consumes from a Queue, you could just hook
> up
> a forwarder that reads from the Topic and writes to the Queue.  It's clear
> then that the message is going to system B (only).  
	[Leslie Mann (2147)]  
	I still think you can do this with a topic if you have a mechanism
where only
	system B can respond such as outlined above. Anybody can look at the
	message, only system B would be able to get a response back to A.
Would
	this allow us to get away with only a single HL7 topic?  From a JMS
perspective
	I don't think it matters whether a message is "outbound" or
"inbound", they are 
	all messages.  The real trick is in filtering what you pass and
respond to.

> This doesn't prevent you from going through intermediate topics.  For
> example let's say systems C, D, and E need ADT messages from system A.
> You
> could have a forwarder that reads from the system A topic and posts to an
> intermediate topic (let's call it "System_A_ADT") using a selector that
> gets
> only ADT messages.  Then you could set up three pass-through agents to
> read
> from System_A_ADT and write to the outbound queues of systems C, D, and E.
> In other words a message could bounce all over the place within JMS, but
> once it's "outbound" I think it should be bound somewhere in particular.
> Does that make sense?  
	[Leslie Mann (2147)]  
	I agree that an "outbound", or for that matter an "inbound", message
should
	be headed for a single HL7 replying destination.  However I think it
would
	be simpler to put all messages on a single topic and let anyone who
wants
	to listen pull off what they want, subject to security, etc and then
only let
	a single correct reponse back. Could not the reply mechanism I
outlined 
	above also be extended to handle pass-through messages?

	The idea of having FormatConvertors and ContentConvertor could
perhaps be 
	used here as well, how about a ReplyFilter?  The ReplyFilter would
only
	allow responses based on HL7 rules.

	Leslie