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

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

Bryan:

> -----Original Message-----
> From:	Tripp, Bryan [SMTP:Bry...@uh...]
> Sent:	Thursday, October 10, 2002 10:26 AM
> To:	'Leslie Mann (2147)'
> Cc:	Guevara, Alexei; hl7...@li...
> Subject:	RE: [HAPI-devel] [for review] use case for "Processing and
> forwar ding hl7 query me ssages"
> 
> 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?  
	[Leslie Mann]  
	Yep, thats the basic idea although I think we would need to be able
to distinguish between a JMS response and an HL7 response.  The bridge
should allow JMS responses back into the JMS message topic cloud but filter
HL7 responses into the HL7 reply queue.  This would allow an app to act on
received messages An example would be like some sort of monitoring
application.  It could see all messages and based on message content send
out JMS messages that other listeners may act on but may be restricted to
actually responding in an HL7 fashion to the original message source.

> 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?  
	[Leslie Mann]  
	Probably.  I have been reviewing the JMS1.1 specs and they are
actually moving to a common interface between Queues and Topics.  The
Destination interface may simplify things for later JMS versions.
> 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?  
	[Leslie Mann]  
	Good points.  In response to 1) if you are sticking a HAPI bridge
into the HL7 stream wouldn't you know administratively what the destination
identity is?  For example my Meditech -> PACS interface has an ADT,orders,
and results point to point structure. I know where the destination of each
message is even if the apps themselves do not. If the fields cannot get
populated by vendor would not the knowledge of you HL7 network allow you to
configure the bridge to set the correct values to the JMS properties to make
this reply mechanism work.

	2) Does this happen in the real HL7 world?  Any HL7 guru who can
comment?

	Leslie