hl7api-devel — developer list

RE: [HAPI-devel] new validation model

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

Hi Alexei, 

Great idea, I hadn't thought of using regular expressions but of course it's
a good way to do it.  I bet most of the datatype rules could be implemented
in that way.  

That said, I'd prefer to implement at least the standard rules as classes
(even if they just contain regular expressions) than put the expressions
themselves in a file, because: 

1) These rules are part of the standard, so fairly static.  I'm guessing it
will be relatively uncommon to want to edit them.  

2) Not all datatype rules would be best implemented as regular expressions
... for example dates (probably better to use a GregorianCalendar) and
validating vocabularly against tables.  

3) It would also be nice to keep the class structure fairly similar to the
MessageRules and EncodingRules (where we can't use regular expressions).  

How about this ... we use individual classes for the standard rules, and
also create a RegularExpressionRule class that could be configured with some
arguments in the property file.  Like this: 

ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on
ca.uhn.hl7v2.validation.datatype.RegularExpressionRule = TN,/^(\d{3})
\d{3}-\d{4}$/

How does that sound?  

I realize we might end up with a lot of rule classes, which at some point
would become annoying.  Maybe we should get a rough count of the rules
fairly soon?   

Bryan 

> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: October 11, 2002 12:52 PM
> To: 'hl7...@li...'
> Subject: RE: [HAPI-devel] new validation model
> 
> 
> ... Maybe this validation module is a perfect fit for regular
> expressions, and even more now that the jdk1.4 has optimized 
> support for
> it ... we could have a file with global validation rules, expressed as
> regular expressions (for data types), but the end user will be able to
> override those rules as well in some user suplied file ...
> 
> alex6
> 
> -----Original Message-----
> From: Tripp, Bryan
> To: 'hl7...@li...'
> Sent: 10/11/2002 12:44 PM
> Subject: [HAPI-devel] new validation model
> 
> Hi Everyone, 
> 
> I've been speaking with Alan Shields and Neal Acharya about a new
> validation
> model for HAPI.  This seems like a good candidate for a new 
> sub-project,
> so
> if anyone is interested in working on this please let us know.  
> 
> Currently, the only run-time message validation HAPI performs 
> is within
> the
> setValue() methods of the Primitive datatype classes.  For 
> example when
> you
> call setValue() on a DT an exception is thrown if the String 
> arg is not
> in
> the correct DT format.  This has served pretty well so far 
> but it leaves
> us
> with the following limitations: 
> 
> 1. Sometimes validation is inappropriate.  This is the 
> problem Alan ran
> into
> -- the TN class was rejecting his perfectly valid UK telephone numbers
> because they didn't conform to the North American format.  
> 2. Can't add further optional constraints (such as all timestamps must
> have
> a time zone).  
> 3. Can't turn off validation to improve performance. 
> 3. Other forms of validation (e.g. conformance profiles, 
> standard DTDs)
> are
> not covered.  
> 
> We're considering expanding run-time validation and making it
> configurable.
> In a nutshell, the idea is to implement each validation rule as a Rule
> object with a test() method that could be invoked or not, depending on
> run-time configuration.  Three types of rules seem appropriate: 
> 
> 1. DataTypeRule: Called when the values of simple datatypes are set,
> like
> the existing hard-coded datatype validations (e.g.
> TNFollowsNorthAmericanFormat).  
> 2. MessageRule: Called when complete message content is to be 
> checked on
> a
> parsed message (e.g. conformance profile). 
> 3. EncodingRule: Applied to an encoded message (e.g. 
> validation against
> a
> 2.xml Schema, a rule that prohibits empty tags, etc.).
> 
> We would attempt to ship HAPI with all the rules identified by the HL7
> standard, enabled by default, and called at logical points in message
> processing.  Users could disable the rules, call the rules
> programmatically
> at different points in their own code, and create their own rules if
> they
> wish.  Rules could be turned on and off at run-time, possibly 
> by editing
> a
> property file with one entry per class, like this (the entries below
> refer
> to implementations of DataTypeRule):
> 
> ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
> ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on
> 
> The beginnings of a suggested class structure are attached.  
> 
> Is anyone else interested in working on this?  Feedback is 
> most welcome.
> 
> 
> Thanks, 
> Bryan 
> 
> 
> 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.
> 
>   
> 
>  <<validation.gif>> 
> 
> 
> 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 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.

RE: [HAPI-devel] new validation model

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

... Maybe this validation module is a perfect fit for regular
expressions, and even more now that the jdk1.4 has optimized support for
it ... we could have a file with global validation rules, expressed as
regular expressions (for data types), but the end user will be able to
override those rules as well in some user suplied file ...

alex6

-----Original Message-----
From: Tripp, Bryan
To: 'hl7...@li...'
Sent: 10/11/2002 12:44 PM
Subject: [HAPI-devel] new validation model

Hi Everyone, 

I've been speaking with Alan Shields and Neal Acharya about a new
validation
model for HAPI.  This seems like a good candidate for a new sub-project,
so
if anyone is interested in working on this please let us know.  

Currently, the only run-time message validation HAPI performs is within
the
setValue() methods of the Primitive datatype classes.  For example when
you
call setValue() on a DT an exception is thrown if the String arg is not
in
the correct DT format.  This has served pretty well so far but it leaves
us
with the following limitations: 

1. Sometimes validation is inappropriate.  This is the problem Alan ran
into
-- the TN class was rejecting his perfectly valid UK telephone numbers
because they didn't conform to the North American format.  
2. Can't add further optional constraints (such as all timestamps must
have
a time zone).  
3. Can't turn off validation to improve performance. 
3. Other forms of validation (e.g. conformance profiles, standard DTDs)
are
not covered.  

We're considering expanding run-time validation and making it
configurable.
In a nutshell, the idea is to implement each validation rule as a Rule
object with a test() method that could be invoked or not, depending on
run-time configuration.  Three types of rules seem appropriate: 

1. DataTypeRule: Called when the values of simple datatypes are set,
like
the existing hard-coded datatype validations (e.g.
TNFollowsNorthAmericanFormat).  
2. MessageRule: Called when complete message content is to be checked on
a
parsed message (e.g. conformance profile). 
3. EncodingRule: Applied to an encoded message (e.g. validation against
a
2.xml Schema, a rule that prohibits empty tags, etc.).

We would attempt to ship HAPI with all the rules identified by the HL7
standard, enabled by default, and called at logical points in message
processing.  Users could disable the rules, call the rules
programmatically
at different points in their own code, and create their own rules if
they
wish.  Rules could be turned on and off at run-time, possibly by editing
a
property file with one entry per class, like this (the entries below
refer
to implementations of DataTypeRule):

ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on

The beginnings of a suggested class structure are attached.  

Is anyone else interested in working on this?  Feedback is most welcome.


Thanks, 
Bryan 


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.

  

 <<validation.gif>> 


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.

[HAPI-devel] new validation model

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

Hi Everyone, 

I've been speaking with Alan Shields and Neal Acharya about a new validation
model for HAPI.  This seems like a good candidate for a new sub-project, so
if anyone is interested in working on this please let us know.  

Currently, the only run-time message validation HAPI performs is within the
setValue() methods of the Primitive datatype classes.  For example when you
call setValue() on a DT an exception is thrown if the String arg is not in
the correct DT format.  This has served pretty well so far but it leaves us
with the following limitations: 

1. Sometimes validation is inappropriate.  This is the problem Alan ran into
-- the TN class was rejecting his perfectly valid UK telephone numbers
because they didn't conform to the North American format.  
2. Can't add further optional constraints (such as all timestamps must have
a time zone).  
3. Can't turn off validation to improve performance. 
3. Other forms of validation (e.g. conformance profiles, standard DTDs) are
not covered.  

We're considering expanding run-time validation and making it configurable.
In a nutshell, the idea is to implement each validation rule as a Rule
object with a test() method that could be invoked or not, depending on
run-time configuration.  Three types of rules seem appropriate: 

1. DataTypeRule: Called when the values of simple datatypes are set, like
the existing hard-coded datatype validations (e.g.
TNFollowsNorthAmericanFormat).  
2. MessageRule: Called when complete message content is to be checked on a
parsed message (e.g. conformance profile). 
3. EncodingRule: Applied to an encoded message (e.g. validation against a
2.xml Schema, a rule that prohibits empty tags, etc.).

We would attempt to ship HAPI with all the rules identified by the HL7
standard, enabled by default, and called at logical points in message
processing.  Users could disable the rules, call the rules programmatically
at different points in their own code, and create their own rules if they
wish.  Rules could be turned on and off at run-time, possibly by editing a
property file with one entry per class, like this (the entries below refer
to implementations of DataTypeRule):

ca.uhn.hl7v2.validation.datatype.TNFollowsNorthAmericanFormat = off
ca.uhn.hl7v2.validation.datatype.TNFollowsUKFormat = on

The beginnings of a suggested class structure are attached.  

Is anyone else interested in working on this?  Feedback is most welcome.  

Thanks, 
Bryan 


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.

  

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 

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.

[HAPI-devel] hapi/jms meeting

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

When: Wednesday, October 16, 2002 3:00 PM-5:00 PM (GMT-05:00) Eastern Time
(US & Canada).
Where: Lucliff Conference Room 2040

*~*~*~*~*~*~*~*~*~*




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.

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

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

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

Alexei:

I am good any time after 09:00 next Wed, Oct 16.

Leslie

> -----Original Message-----
> From:	Guevara, Alexei [SMTP:Ale...@uh...]
> Sent:	Wednesday, October 09, 2002 12:24 PM
> To:	hl7...@li...
> Subject:	RE: [HAPI-devel] [for review] use case for "Processing and
> forwar ding hl7 query me ssages"
> 
> 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
> 
> 
> 

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

[Alex H. <al...@9p...>]

It works for me if it is before 4pm cst.

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of Guevara,
Alexei
Sent: Wednesday, October 09, 2002 11:24 AM
To: hl7...@li...
Subject: RE: [HAPI-devel] [for review] use case for "Processing and forwar
ding hl7 query me ssages"

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:lm...@TA...]
>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.



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

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:lm...@TA...] 
>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.

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

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

Hi Leslie, 

Thanks very much for the comments.  Responses below ... 


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

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

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

I couldn't have elaborated better myself :) 

>Are you thinking about having multiple inbound XML,
> traditional, etc topics with conversions/formatting done at 
> source rather
> than at destination?

I think we're on the same page ... you would massage the messages with
topic-convertor chains, and JMS clients could grab messages from whatever
Topic has them in the form they want.  

Bryan 


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.

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

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

Hi Alexei, 

We're making good progress.  Comments below ... 


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. 

Sounds like a good idea, but at the same time I think it adds some
complexity to the hapi/jms component. What about having two kind of bridges,
one for queues and another for topics (they both will inherit from some base
bridge class). In this case the client will know what to expect from the
bridge, and the bridge responsabilities will be clearly defined.
In the case of the topic bridge, we can choose to send back to the client
only the first response, send all the responses back (over a defined period
of time) and create a compound HL7 message with all the received responses
over a period of time) 

<bryan> 
I see your point, it could be pretty confusing.  Another way to allow either
a Topic or Queue would be to have multiple constructors, for example: 

	JMSBridge(Queue inbound, Queue response) { ... }

	/** If singleReply, only the first response to a given message 
	 * is forwarded and others are discarded */
	JMSBridge(Topic inbound, Queue response, boolean singleReply) { ...
}

The nice thing about doing it this way is that we could potentially sneak in
other options (as additional constructors) without confusing too many
people: 

	/** Can't reply */
	JMSBridge(Topic inbound) { ... }

	/** Copies of msg go to inbound Topic and Queue.  The Queue copy 
	 * has its reply-to field set to the outbound Queue, so that only
one 
	 * client can reply. */
	JMSBridge(Topic inboundTopic, Queue inboundQueue, Queue response) {
... }

... who reads all the constructors anyway?  The reason I like the last
option is that it makes sure that only one client responds (rather than
quietly discarding some responses).  However I agree that it's too wierd to
be the only option.  

</bryan>

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

Does this means than when a query is received, it is acknowledged first
(accept acknowledgement) and after, the real response is sent as a new
message, that the receiving party will have to ack) ... 

<bryan> yes </bryan>

I don't understand clearly the concept of "looking up outbound destinations
by name", is that part of the hl7 std. or is a way you propose to solve the
problem that we could have with the same query being answered by many
systems ?
(here again, we can use the concept of compound query responses, meaning
that the bridge will collect all the query responses received within a
certain period of time and will send them back the the client as a single
hl7 message) is this viable ?

<bryan> 
I was just looking for a nice way to handle cases where you want to send a
message to a particular system and you know that system's name.  The
"application acknowledgements" and "deferred responses" are an example.
They are separate message exchanges initiated by the original receiver -- I
think it's common for systems to expect new message exchanges on a different
port than responses, so you couldn't necessarily use the reply-to Queue.
Also, the new message exchange might happen much later (e.g. off-peak), so
it wouldn't necessarily be convenient to hold on to an object reference even
if you did want the reply-to Queue.  

About compounding responses from multiple clients ... I'm not sure what to
think about this ... a couple of questions for now: 

1) How do we know when all the responses have come back?  We could wait a
specified amount of time but the longer you wait the longer the remote
system waits, and you would have to wait pretty long to be sure that there
were no stragglers.    

2) There are a lot of different response message structures.  Is there a
general algorithm for finding which parts to compound? 

</bryan> 

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

yes, this is definitely needed and it is is missing. For the time being I
think your proposal is good. In the long term, we should probably refactor
the whole connection framework to be able to accommodate any type of
connection.

<bryan> Agreed.  </bryan>


kool, these ( 5,6) are very interesting features, that will make the
hapi/jms bridge very powerful ( it could be the beginnings of an interface
engine). And at the same time, they are not hard to implement, so yes, let's
bring it in!!! (at the hapi/jms level for the time being, we could make this
a general approach at the moment when we decide to refactor the connection
framework)

<bryan> Great, let's do it. </bryan>

Bryan 


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.

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

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

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

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

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

Hey Bryan, thanks for your comments, I think they are very helpful. I'll try
to establish a question/answer type of communication here, like in a
conference call ;)

 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. 

Sounds like a good idea, but at the same time I think it adds some
complexity to the hapi/jms component. What about having two kind of bridges,
one for queues and another for topics (they both will inherit from some base
bridge class). In this case the client will know what to expect from the
bridge, and the bridge responsabilities will be clearly defined.

In the case of the topic bridge, we can choose to send back to the client
only the first response, send all the responses back (over a defined period
of time) and create a compound HL7 message with all the received responses
over a period of time) ... 

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

Does this means than when a query is received, it is acknowledged first
(accept acknowledgement) and after, the real response is sent as a new
message, that the receiving party will have to ack) ... 

I don't understand clearly the concept of "looking up outbound destinations
by name", is that part of the hl7 std. or is a way you propose to solve the
problem that we could have with the same query being answered by many
systems ?

(here again, we can use the concept of compound query responses, meaning
that the bridge will collect all the query responses received within a
certain period of time and will send them back the the client as a single
hl7 message) is this viable ?

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

yes, this is definitely needed and it is is missing. For the time being I
think your proposal is good. In the long term, we should probably refactor
the whole connection framework to be able to accommodate any type of
connection.

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

kool, these ( 5,6) are very interesting features, that will make the
hapi/jms bridge very powerful ( it could be the beginnings of an interface
engine). And at the same time, they are not hard to implement, so yes, let's
bring it in!!! (at the hapi/jms level for the time being, we could make this
a general approach at the moment when we decide to refactor the connection
framework)

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

Bryan 

alex6

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

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.

RE: [HAPI-devel] sample message library

[Alex H. <al...@9p...>]

I can submit a few messages from our test environment. They are all 'A' type
messages for version 2.2.

Also, someplace I have lying around some code that parses HL7 messages out
of a file in a similar manner to the way you describe. I'll track that down
as well.

-Alex

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of Tripp, Bryan
Sent: Wednesday, October 02, 2002 4:28 PM
To: 'hl7...@li...'
Subject: [HAPI-devel] sample message library

It would be nice to have a shared library of HL7 messages to use in
functional testing of HAPI.  The more varied these messages the better (e.g.
from different systems, different hospitals).  I'll compile such a library
if everyone sends me a few messages.  This would be posted on the web site,
so obviously remove any identifying patient information before sending them
to me.  The benefit of sumbitting something is that then HAPI will be
periodically tested against *your* messages.

In order to write a testing utility we will have to agree on a way of
packaging test messages.  My suggestion is to put them in a text file with a
blank line between them (i.e. message, blank line, message, blank line,
etc.).  Then we could put all the files in a JAR and point a test utility at
them.  The test utility would probably just parse all the messages and
report any exceptions.  This utility is of course in addition to the
extensive JUnit test suite that I keep hoping will materialize (any
volunteers?).

What does everyone think?  Does anyone want to write the tester?

Thanks,
Bryan


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

RE: [HAPI-devel] adding Secure Sockets to HAPI

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

On second thought, maybe we could do this right now.  For the secure server,
a boolean arg could be added to the constructor of
ca.uhn.hl7v2.app.HL7Service, and we could have a factory method that
provides either a normal ServerSocket or SSLServerSocket based on the value
provided.  Something like this (I'm pretty much just cutting and pasting
from the DDJ article here): 

    protected ServerSocket createServerSocket(int port) throws Exception {
        ServerSocket ss = null;
        if (this.secure) {
            SSLServerSocketFactory ssf = null;
            // set up key manager to do server authentication
            KeyManagerFactory kmf = KeyManagerFactory.getInstance( "SunX509"
);
            KeyStore ks = KeyStore.getInstance( "JKS" );
            char[] passphrase = "passphrase".toCharArray();
            ks.load(new FileInputStream("testkeys"), passphrase);
            kmf.init(ks, passphrase);
            TrustManagerFactory tmf =
TrustManagerFactory.getInstance("SunX509");
            tmf.init( ks );
            SSLContext ctx = SSLContext.getInstance( "TLS" );
            ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
            ssf = ctx.getServerSocketFactory();
            ss = ssf.createServerSocket(port);
        } else {
            ss = ServerSocketFactory.getDefault().createServerSocket(port);
        }
        return ss;        
    }

... then subclasses could get their ServerSockets from this method instead
of making their own.  It looks like something pretty similar could be done
in ConnectionHub.  

Does that make sense?  Personally I am not very familiar with this stuff, so
I don't really feel comfortable implementing it.  Is there anyone on the
list with SSL experience who would like to do this?  

Bryan 


> -----Original Message-----
> From: Tripp, Bryan [mailto:Bry...@uh...]
> Sent: October 2, 2002 5:02 PM
> To: Guevara, Alexei; hl7...@li...
> Subject: RE: [HAPI-devel] adding Secure Sockets to HAPI
> 
> 
> I agree, this is definitely something we should add.  We'll 
> have to work
> this in to the next revision of the app package.  This 
> package is due for
> some revision anyway, to pave the way for adding HTTP and 
> SOAP support.   
> 
> In the mean time, it should be possible to use an SSL socket 
> in HAPI by
> providing it to the constructor of 
> ca.uhn.hl7v2.app.Connection, although I
> haven't tried it.  ConnectionHub and HL7Service can't be used though. 
> 
> Bryan 
> 
> > -----Original Message-----
> > From: Guevara, Alexei [mailto:Ale...@uh...]
> > Sent: October 2, 2002 3:22 PM
> > To: hl7...@li...
> > Subject: RE: [HAPI-devel] adding Secure Sockets to HAPI
> > 
> > 
> > That sounds like a good idea, as that is one of the possible 
> > approaches to
> > send HL7 feeds through the internet.
> > 
> > alex6
> > 
> > > -----Original Message-----
> > > From: Joe Quinn [mailto:qu...@em...]
> > > Sent: Wednesday, October 02, 2002 3:12 PM
> > > To: hl7...@li...
> > > Subject: [HAPI-devel] adding Secure Sockets to HAPI
> > > 
> > > Any interest in extending the communications part of HAPI 
> > to allow use of
> > > Secure Sockets as well as Sockets?
> > > 
> > > There is a  terrific article in Dr. Dobb's Journal from Feb 
> > 2001 which
> > > describes an approach which might be used.
> > > 
> > > http://www.ddj.com/documents/s=870/ddj0102a/0102a.htm
> > > 
> > > 
> > > 
> > > Joe Quinn
> > > Data Integration Specialist
> > > The Children's Hospital of Philadelphia
> > > 34th Street & Civic Center Boulevard
> > > Philadelphia, PA  19104-4399
> > > (215) 590-1573
> > > qu...@em...   www.chop.edu
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > 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.
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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.
> 
> 
> 
> -------------------------------------------------------
> 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.

[HAPI-devel] sample message library

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

It would be nice to have a shared library of HL7 messages to use in
functional testing of HAPI.  The more varied these messages the better (e.g.
from different systems, different hospitals).  I'll compile such a library
if everyone sends me a few messages.  This would be posted on the web site,
so obviously remove any identifying patient information before sending them
to me.  The benefit of sumbitting something is that then HAPI will be
periodically tested against *your* messages.  

In order to write a testing utility we will have to agree on a way of
packaging test messages.  My suggestion is to put them in a text file with a
blank line between them (i.e. message, blank line, message, blank line,
etc.).  Then we could put all the files in a JAR and point a test utility at
them.  The test utility would probably just parse all the messages and
report any exceptions.  This utility is of course in addition to the
extensive JUnit test suite that I keep hoping will materialize (any
volunteers?).  

What does everyone think?  Does anyone want to write the tester?  

Thanks, 
Bryan 


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.

RE: [HAPI-devel] adding Secure Sockets to HAPI

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

I agree, this is definitely something we should add.  We'll have to work
this in to the next revision of the app package.  This package is due for
some revision anyway, to pave the way for adding HTTP and SOAP support.   

In the mean time, it should be possible to use an SSL socket in HAPI by
providing it to the constructor of ca.uhn.hl7v2.app.Connection, although I
haven't tried it.  ConnectionHub and HL7Service can't be used though. 

Bryan 

> -----Original Message-----
> From: Guevara, Alexei [mailto:Ale...@uh...]
> Sent: October 2, 2002 3:22 PM
> To: hl7...@li...
> Subject: RE: [HAPI-devel] adding Secure Sockets to HAPI
> 
> 
> That sounds like a good idea, as that is one of the possible 
> approaches to
> send HL7 feeds through the internet.
> 
> alex6
> 
> > -----Original Message-----
> > From: Joe Quinn [mailto:qu...@em...]
> > Sent: Wednesday, October 02, 2002 3:12 PM
> > To: hl7...@li...
> > Subject: [HAPI-devel] adding Secure Sockets to HAPI
> > 
> > Any interest in extending the communications part of HAPI 
> to allow use of
> > Secure Sockets as well as Sockets?
> > 
> > There is a  terrific article in Dr. Dobb's Journal from Feb 
> 2001 which
> > describes an approach which might be used.
> > 
> > http://www.ddj.com/documents/s=870/ddj0102a/0102a.htm
> > 
> > 
> > 
> > Joe Quinn
> > Data Integration Specialist
> > The Children's Hospital of Philadelphia
> > 34th Street & Civic Center Boulevard
> > Philadelphia, PA  19104-4399
> > (215) 590-1573
> > qu...@em...   www.chop.edu
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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.
> 
> 
> 
> -------------------------------------------------------
> 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.

RE: [HAPI-devel] patching/bug-reporting process

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

Hi Gigado, 

Yes, I get an email notification whenever a bug is submitted.  Thanks for
the patch, it looks good.  

Bryan 

> -----Original Message-----
> From: Immanuel, Gidado-Yisa [mailto:av...@cd...]
> Sent: October 2, 2002 1:55 PM
> To: hl7...@li...
> Subject: [HAPI-devel] patching/bug-reporting process
> 
> 
> I just submitted a bug+patch request.  I have not used
> sourceforge all that much, thus my question is: what's
> the notification mechanism when new bugs are added to
> the tracker?  Are the project owners automatically
> notified, or do I need to assign it to someone, or do
> I need to post the developer mailing-list (like I'm
> doing now :)
> 
> Thanks,
> Gidado
> 
> 
> -------------------------------------------------------
> 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.

RE: [HAPI-devel] adding Secure Sockets to HAPI

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

That sounds like a good idea, as that is one of the possible approaches to
send HL7 feeds through the internet.

alex6

> -----Original Message-----
> From: Joe Quinn [mailto:qu...@em...]
> Sent: Wednesday, October 02, 2002 3:12 PM
> To: hl7...@li...
> Subject: [HAPI-devel] adding Secure Sockets to HAPI
> 
> Any interest in extending the communications part of HAPI to allow use of
> Secure Sockets as well as Sockets?
> 
> There is a  terrific article in Dr. Dobb's Journal from Feb 2001 which
> describes an approach which might be used.
> 
> http://www.ddj.com/documents/s=870/ddj0102a/0102a.htm
> 
> 
> 
> Joe Quinn
> Data Integration Specialist
> The Children's Hospital of Philadelphia
> 34th Street & Civic Center Boulevard
> Philadelphia, PA  19104-4399
> (215) 590-1573
> qu...@em...   www.chop.edu
> 
> 
> 
> 
> -------------------------------------------------------
> 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.

[HAPI-devel] adding Secure Sockets to HAPI

[Joe Q. <qu...@em...>]

Any interest in extending the communications part of HAPI to allow use of =
Secure Sockets as well as Sockets?

There is a  terrific article in Dr. Dobb's Journal from Feb 2001 which =
describes an approach which might be used.

http://www.ddj.com/documents/s=3D870/ddj0102a/0102a.htm



Joe Quinn
Data Integration Specialist
The Children's Hospital of Philadelphia
34th Street & Civic Center Boulevard
Philadelphia, PA  19104-4399
(215) 590-1573
qu...@em...   www.chop.edu

[HAPI-devel] patching/bug-reporting process

[Immanuel, Gidado-Y. <av...@cd...>]

I just submitted a bug+patch request.  I have not used
sourceforge all that much, thus my question is: what's
the notification mechanism when new bugs are added to
the tracker?  Are the project owners automatically
notified, or do I need to assign it to someone, or do
I need to post the developer mailing-list (like I'm
doing now :)

Thanks,
Gidado

RE: [HAPI-devel] new Project Manager

[Harriet H. <har...@ro...>]

Hi all,

My pleasure to join HAPI, and thanks for having me.

I always believe that development is a team effort, and I am impressed by
the highly competent team that we have here in HAPI. My intention is to help
developing an "open organization" that facilitate better collaboration and
ultimately provide a high quality product, and I am looking forward to
working with you all.

Regards,
Harriet Hu, PMP

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of Tripp,
Bryan
Sent: Tuesday, October 01, 2002 11:05 AM
To: 'hl7...@li...'
Subject: [HAPI-devel] new Project Manager


I'm very pleased to announce that HAPI now has a Project Manager, Harriet Hu
(har...@ro...).

Harriet has a B.E. in Electronic Engineering and 9 years experience in the
IT field.  She has managed high-visibility projects for fortune 500 clients,
large institutions as well as small and mid-sized companies.  Harriet's
project management experience includes all project phases, team building,
client management, estimating, and contracts management.  Harriet is a
member of the Project Management Institute and is a certified PMP (Project
Management Professional).

Harriet will lead development of the organizational component of HAPI.  She
has already been working with me on defining clear roles within HAPI that
volunteers can play, and introducing some basic organizational documentation
to the web site.  Her next task will be to develop workflows for various
volunteer roles so that people who want to contribute to HAPI will have an
easier time getting started.

Please join me in welcoming Harriet to the team.

Bryan

Bryan Tripp, MSc
Senior Technical Specialist, University Health Network (www.uhn.ca)
Chief Developer, HAPI (hl7api.sourceforge.net)


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 sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

[HAPI-devel] new Project Manager

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

I'm very pleased to announce that HAPI now has a Project Manager, Harriet Hu
(har...@ro...).  

Harriet has a B.E. in Electronic Engineering and 9 years experience in the
IT field.  She has managed high-visibility projects for fortune 500 clients,
large institutions as well as small and mid-sized companies.  Harriet's
project management experience includes all project phases, team building,
client management, estimating, and contracts management.  Harriet is a
member of the Project Management Institute and is a certified PMP (Project
Management Professional).

Harriet will lead development of the organizational component of HAPI.  She
has already been working with me on defining clear roles within HAPI that
volunteers can play, and introducing some basic organizational documentation
to the web site.  Her next task will be to develop workflows for various
volunteer roles so that people who want to contribute to HAPI will have an
easier time getting started.  

Please join me in welcoming Harriet to the team.  

Bryan 

Bryan Tripp, MSc
Senior Technical Specialist, University Health Network (www.uhn.ca)
Chief Developer, HAPI (hl7api.sourceforge.net)


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.