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

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

Hi Leslie, 

Great idea, I like this much better than what I was thinking.  To make sure
I understand correctly ... each bridge is associated with one application,
and has properties that contain that application's name and facility.  When
a bridge gets an outbound message, it only returns a response if the
receiving application and facility fields of the message match its own.
Otherwise it discards any response it receives.  Is that right?  

Does this eliminate the need to speak in terms of Queues and Topics?  Can we
write all the HAPI code using the Destination interface and leave the choice
of Queue or Topic up to the user?  

I like this plan a lot but there are a couple of minor things that bother
me: 

1) Receiving application and receiving facility are optional fields, and in
my limited experience not populated very often.  
2) As far as I know HL7 doesn't prohibit an application from responding to a
message that isn't addressed to it (maybe because of the point-to-point
focus).  

Will these be problematic?  In some cases users will be able to get their
system vendors to populate these fields as needed.  If not, then the sending
application probably thinks it is sending everything to one place, and we
could make this so by munging the header on the way through JMS.  Will that
work?  

Bryan 

> -----Original Message-----
> From: Leslie Mann (2147) [mailto:lm...@TA...]
> Sent: October 9, 2002 10:42 PM
> To: 'Tripp, Bryan'
> Cc: Guevara, Alexei; hl7...@li...
> Subject: RE: [HAPI-devel] [for review] use case for "Processing and
> forwar ding hl7 query me ssages"
> 
> 
> 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
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> 


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.