hl7api-devel — developer list

[HAPI-devel] hi, patch to load a default class when no message-class mapping is found

[alexei g. <ale...@ho...>]

Hi 
 
I was in need of making hapi parse any kind of HL7 messages (including
custom ones, not kown at deployment time). To accomplish such behavior I've
changed the Parser.findMessageClass, check the javadocs of that method
(included in the attached zip file) for details.
 
alex6
PS: a very simple test case is included in the zip file as well.

MailFiler <http://www.mailfiler.com>  [AG-7IS2CX]

[HAPI-devel] =?utf-8?B?UkU6IFtIQVBJLWRldmVsXSBhZGRpbmcgWiBzZWdtZW50cw==?=

[<Bry...@uh...>]

Just a couple of related notes ... 
 
1) If you don't have the database, you can still do this but the procedure
is different.  You have to write the Z-segment class manually, write a
modified message class that references it, and "register" these as described
in the JavaDocs for ca.uhn.hl7v2.parser.Parser.packageList().  
 
2) I'm working on automatic handling of Z-segments, and plan to have it
ready for version 0.4 (which should be out within a month).  The basic idea
is that any unexpected segment that is encountered during parsing will be
added to the message structure on the fly, and if the segment type isn't
recognized (e.g. because it is a Z-segment) then the segment structure will
also be built on the fly (out of Varies types, unless the message is XML
encoded so that the datatype is declared).  
 
Bryan 

-----Original Message-----
From: Shi...@tr... [mailto:Shi...@tr...]
Sent: April 4, 2003 9:21 AM
To: hl7...@li...
Subject: [HAPI-devel] adding Z segments


Alex,
 
We have customized our message adding Z segment etc. It is a multi-step
process. First you have to modify the access database for the HL7 messages.
Once you have done that then you need to recompile the entire library.
Beware that you want to use the latest version of the HAPI code from the CVS
not the download from the site.  
 
Shin.



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

[<Shi...@tr...>]

QWxleCwNCiANCldlIGhhdmUgY3VzdG9taXplZCBvdXIgbWVzc2FnZSBhZGRpbmcgWiBzZWdtZW50
IGV0Yy4gSXQgaXMgYSBtdWx0aS1zdGVwIHByb2Nlc3MuIEZpcnN0IHlvdSBoYXZlIHRvIG1vZGlm
eSB0aGUgYWNjZXNzIGRhdGFiYXNlIGZvciB0aGUgSEw3IG1lc3NhZ2VzLiBPbmNlIHlvdSBoYXZl
IGRvbmUgdGhhdCB0aGVuIHlvdSBuZWVkIHRvIHJlY29tcGlsZSB0aGUgZW50aXJlIGxpYnJhcnku
ICBCZXdhcmUgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBI
QVBJIGNvZGUgZnJvbSB0aGUgQ1ZTIG5vdCB0aGUgZG93bmxvYWQgZnJvbSB0aGUgc2l0ZS4gIA0K
IA0KU2hpbi4NCg==

[HAPI-devel] subscribe

[Lars J. <Jen...@mh...>]

[HAPI-devel] message profile editor

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

I'm working on the conformance profile package (ca.uhn.hl7v2.conf).  For
those not familiar with profiles, they are XML expressions of
domain-specific constraints on a message.  They are meant to replace the
paper specs that people use to document their HL7 interfaces.  This is new
in HL7 v2.5.  Sooner or later, HAPI will be able to test messages against
profiles on the fly, and produce profile JARs that let you code directly
against an implementation of (for example) McKesson's specific ADT_A01
profile, rather than HL7's less specific ADT_A01 message spec.  

The profile parser is basically working.  It would be nice to have an editor
as well.  A parsed profile is a tree of JavaBeans with String leaf nodes.
Does anyone know of a good, visual, open-source tool for editing such a
thing?  This isn't critical as there is already a free profile editor out
there (written in Delphi), but it would be nice to have.  

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] test hl7 data

[Dylan H. <dy...@go...>]

> If you are just load-testing JMS, what is the argument against
sending,=20
> say, the same 10 messages 10 000 times? =20

That is what I am doing now - I was thinking it would be nice to get a
variety of data.

	Thanks -=20
	Dylan=20



Somebody should really write an HL7 obfuscator using HAPI, so production
data could be used for testing without creating privacy problems.  Any
takers? =20

Bryan=20

> -----Original Message-----
> From: Dylan Hasman [mailto:dy...@go...]
> Sent: January 23, 2003 4:14 PM
> To: hl7...@li...
> Subject: [HAPI-devel] test hl7 data
>=20
>=20
> Hello,
>=20
>             I seem to remember seeing a message about collecting some
> HL7 data for testing.  I need something like 75-100k messages=20
> to do some
> testing.  Has anybody started collecting test data ?  or know where I
> can get some ?
>=20
>             Thanks,
>=20
>             Dylan=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>=20


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] test hl7 data

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

Sorry Dylan, we have very few messages as yet, certainly nothing like what
you need.  Actually we are not aiming for a large volume so much as a wide
variety (for functional testing).  

If you are just load-testing JMS, what is the argument against sending, say,
the same 10 messages 10 000 times?  

Somebody should really write an HL7 obfuscator using HAPI, so production
data could be used for testing without creating privacy problems.  Any
takers?  

Bryan 

> -----Original Message-----
> From: Dylan Hasman [mailto:dy...@go...]
> Sent: January 23, 2003 4:14 PM
> To: hl7...@li...
> Subject: [HAPI-devel] test hl7 data
> 
> 
> Hello,
> 
>             I seem to remember seeing a message about collecting some
> HL7 data for testing.  I need something like 75-100k messages 
> to do some
> testing.  Has anybody started collecting test data ?  or know where I
> can get some ?
> 
>             Thanks,
> 
>             Dylan 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> 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] test hl7 data

[Dylan H. <dy...@go...>]

Hello,

            I seem to remember seeing a message about collecting some
HL7 data for testing.  I need something like 75-100k messages to do some
testing.  Has anybody started collecting test data ?  or know where I
can get some ?

            Thanks,

            Dylan=20

[HAPI-devel] alternative HAPI syntax

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

I should mention an addition to HAPI over the holidays.  This is partly in
response to Alex's question about writing version-independent code, and
partly because drilling down through a message can result in a really long
chain of getters. 

There is a new class, ca.uhn.hl7v2.util.Terser (meaning it lets you write
code that is more "terse" -- if you can think of a better name, speak up).
A Terser acts as a wrapper for a Message object, and provides a new syntax
for setting and getting message fields.  This new syntax is 1) shorter, and
2) version-independent (if you're careful).  

For convenience, here is the class JavaDoc: 

---- 

public class Terser
extends java.lang.Object

Wraps a message to provide access to fields using a terse location
specification syntax. For example: 

terser.set("MSH-9-3", "ADT_A01"); 
can be used instead of 
message.getMSH().getMessageType().getMessageStructure().setValue("ADT_A01");


The syntax of a location spec is as follows: 

location_spec: segment_path_spec "-" field ["(" rep ")"] ["-" component ["-"
subcomponent]] 

... where rep, field, component, and subcomponent are integers
(representing, respectively, the field repetition (starting at 0), and the
field number, component number, and subcomponent numbers (starting at 1).
Omitting the rep is equivalent to specifying 0; omitting the component or
subcomponent is equivalent to specifying 1.

The syntax for the segment_path_spec is as follows: 

segment_path_spec: ["/"] (group_spec ["(" rep ")"] "/")* segment_spec ["("
rep ")"]

... where rep has the same meaning as for fields. A leading "/" indicates
that navigation to the location begins at the root of the message; ommitting
this indicates that navigation begins at the current location of the
underlying SegmentFinder (see getFinder() -- this allows manual navigation
if desired). The syntax for group_spec is: 

group_spec: ["."] ["*"] group_name

Here, a . indicates that the group should be searched for (using a
SegmentFinder) starting at the current location in the message. A "*"
indicates that the given group name is a substring -- the first group with a
name that contains the given group_name as a substring will be matched. 

The segment_spec is analogous to the group_spec. 

As another example, the following subcomponent in an SIU_S12 message: 


msg.getSIU_S12_RGSAISNTEAIGNTEAILNTEAIPNTE(1).getSIU_S12_AIGNTE().getAIG().g
etResourceGroup(1).getIdentifier();


... is referenced by all of the following location_spec: 

/SIU_S12_RGSAISNTEAIGNTEAILNTEAIPNTE(1)/SIU_S12_AIGNTE/AIG-5(1)-1 
/*AIG(1)/SIU_S12_AIGNTE/AIG-5(1)-1 
/*AIG(1)/.AIG-5(1) 

The search function only iterates through rep 0 of each group. Thus if rep 0
of the first group in this example was desired instead of rep 1, the
following syntax would also work (since there is only one AIG segment
position in SUI_S12): 

/.AIG-5(1)


----

This syntax is mainly intended as a shortcut for experienced HAPI users.
The disadvantage is that your navigation through the message is checked at
runtime rather than compile time.  It's in the CVS repository if you want to
try it.  Feedback is welcome. 

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] anyone familiar with OpenEMed?

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

Hi Joe, 

It sounds like a sensible idea to me, but not having any experience with
OpenEMed, I can't really claim to know what I'm talking about.   

The OpenEMed people might have something to say on this subject.  I think
they do have some HL7 functionality.  I dimly recall a conversation with
someone named Richard Schilling a while back -- I think he was involved with
OpenEMed and planning to work on its HL7 code, some of which was already
there.  He was aware of HAPI at the time but I'm not sure if he ended up
using it.  

I haven't met David Forslund, but I think he mentioned HAPI on another
mailing list not too long ago.  Again, very dim memory, I'm not even
completely sure it was him.  The point is that they may have more
intelligent comments than I do :)  

Good luck, it's certainly worth looking into.  

Bryan 

> -----Original Message-----
> From: Joe Quinn [mailto:qu...@em...]
> Sent: January 8, 2003 1:41 PM
> To: hl7...@li...
> Subject: [HAPI-devel] anyone familiar with OpenEMed?
> 
> 
> I ran across an interesting Open Source application at 
> http://openmed.sourceforge.net/ and had some correspondence 
> with one of the developers (attached).  I am thinking of 
> using it as the basis of an Immunization Registry. A terrific 
> diagram of the architecture can be found at 
> http://tmed.openemed.net/OpenEMed/TeleMed/.
> 
> Here's my idea (half-baked).  I will bet that OpenEMed does 
> not have a facility to send/receive HL7 messages.  Anyone 
> interested in merging HAPI into OpenEMed?
> 
> Your comments/thoughts/ideas/suggestions welcome.
> 
> 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] anyone familiar with OpenEMed?

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

I ran across an interesting Open Source application at http://openmed.sourc=
eforge.net/ and had some correspondence with one of the developers =
(attached).  I am thinking of using it as the basis of an Immunization =
Registry. A terrific diagram of the architecture can be found at http://tme=
d.openemed.net/OpenEMed/TeleMed/.

Here's my idea (half-baked).  I will bet that OpenEMed does not have a =
facility to send/receive HL7 messages.  Anyone interested in merging HAPI =
into OpenEMed?

Your comments/thoughts/ideas/suggestions welcome.

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

[<alb...@ya...>]

I would like to know more about your volunteer opportunities. 

thanks

Alberto Ramos, SCJP2

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[HAPI-devel] re questions

[Bryan T. <bry...@ya...>]

Hi Alex, 

Still in China, just checking mail from an internet cafe.  To answer your questions, Z segments (if they are not recognized, ie you don't make a custom message), will just be ignored (no exception thrown).  In a couple of months I want to have these parse into generic segment objects so they are there if you need them -- for now if you need to access data from a Z segment you have to make a custom message class.  

Message classes that work with all versions is tricky.  Often the structure changes slightly between versions (eg ST changes to CE).  In the long term there may be a way around this but it is a long way out -- it needs the conformance classes project, which will be complete around April (let me know if you want more details).  For now if you want to switch HL7 versions you have to make code changes.  It sounds like a pain but in my experience it only takes a few minutes (just try to compile with the new version and fix the errors).  

Hope this helps.  

Bryan 



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

[HAPI-devel] adding Z segments

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

If a custom Z segment is added to a message type, do I need to do anything
in particular to configure the message classes? It is likely that this Z
segment will carry data that my application is not interested but I’d like
to know if the parser will by default parse Z segments in a message or does
it throw an exception?

Thanks,

-Alex

[HAPI-devel] HL7 2.4 message: Where is the ADT_A04, A08...?

[Steve G. <eai...@ya...>]

function SetDomain(d) { document.domain = d; }In C:\tmp\HAPI_Guide\hapi_0.3_source_24\ca\uhn\hl7v2\model\v24\message

Where is the ADT_A04, A08...?

I can only see:

ADT_A01.java
ADT_A02.java
ADT_A03.java
ADT_A05.java
ADT_A06.java
ADT_A09.java
ADT_A15.java
ADT_A16.java
ADT_A17.java
ADT_A18.java
ADT_A20.java
ADT_A21.java
ADT_A24.java
ADT_A30.java
ADT_A37.java
ADT_A38.java
ADT_A39.java
ADT_A43.java
ADT_A45.java
ADT_A50.java
ADT_A52.java
ADT_A54.java
ADT_A60.java
ADT_A61.java




---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

[HAPI-devel] avoiding duplicate code

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

I’ve been working on a small system to extract demographic data from HL7 ADT
messages. Up until now I’ve only worked with version 2.2. However, in the
future I’d like my application to be flexible enough to move among different
versions of HL7, realizing that there will be differences to be coded
against in each version.

In reviewing some of the class hierarchy in HAPI I have noticed that data
types, segment, groups and messages do not derive from a particular base
class. That is, if I write a function to extract data from the PID segment,
then I cannot write a generic function to accept a PID object across all
versions of HL7.

But perhaps I am missing something? Is there a good reason for this and
should I avoid trying to design for a generic case since each version of HL7
needs to be handled specifically? How do others approach this? I’m new to
HL7, but I’d like to minimize any duplication in my code that deals with
extracting information from HL7 messages across versions.

Thanks,

-Alex Harvey

[HAPI-devel] going on vacation

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

The HAPI list has been pretty quiet lately, but I want to let everyone know
that I'll be away for three weeks starting tomorrow.  If any support
questions are posted, please answer if you can.  In particular there is a
group of students that may have some questions during this time.  They are
working on the Conformance Classes subproject.  They know Java but they are
fairly new to HAPI and HL7.  

Good luck with the JMS and Unit Test projects.  I'll talk to you in 3 weeks.


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] errors in beta 3

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

Hi Alex, 
 
Sorry, it looks like I forgot to commit these classes with the others.  They
are there now.  Can you try it again?
 
Bryan 
-----Original Message-----
From: Alex Harvey [mailto:al...@9p...]
Sent: November 11, 2002 1:34 PM
To: Hapi
Subject: [HAPI-devel] errors in beta 3


I've been trying to do a build of beta 3 and found a few errors I can't
figure out. Is Component a missing class or is something not being imported
correctly? Also, is DataTypeRule not up-to-date?
 
Thanks in advance,
 
-Alex
 
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 16, column 13
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 62, column 12
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 72, column 42
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 73, column 9
"DataTypeRule.java": Error #: 300 : class Rule not found in interface
ca.uhn.hl7v2.validation.DataTypeRule at line 35, column 39


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] errors in beta 3

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

I’ve been trying to do a build of beta 3 and found a few errors I can’t
figure out. Is Component a missing class or is something not being imported
correctly? Also, is DataTypeRule not up-to-date?

Thanks in advance,

-Alex

"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 16, column 13
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 62, column 12
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 72, column 42
"Field.java": Error #: 300 : class Component not found in class
ca.uhn.hl7v2.conf.spec.message.Field at line 73, column 9
"DataTypeRule.java": Error #: 300 : class Rule not found in interface
ca.uhn.hl7v2.validation.DataTypeRule at line 35, column 39

[HAPI-devel] Leslie Mann now team lead for unit test project

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

Hi Everyone, 

Leslie Mann has been working on a library of unit tests for HAPI.  He has
done a great job so far, and as of today he has agreed to act as the Team
Leader for this subproject.  

The unit test library is based on JUnit (www.junit.org).  The goal is to
write test harnesses for every public method in HAPI, so that all of HAPI's
functionality can be tested automatically (for example as part of the build
process).  This will be a major factor in maximizing HAPI's reliability in
production.  If anyone wishes to contribute to this subproject from now on,
please get in touch with Leslie at lm...@TA....  

Please join me in welcoming Leslie to this new role.  

Bryan 

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




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] conformance testing in HAPI

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

Dear Conformance SIG Members, 

I am looking for help integrating conformance testing into HAPI.  HAPI is an
open-source 2.x parser written in Java (http://hl7api.sourceforge.net).  It
supports parsing and encoding of messages using both the traditional and XML
encodings, and performs many message transport and validation functions.  We
are working on a new validation model, and I would like to include
validation against static profiles.  As this is an open-source project I
would like to invite interested Conformance SIG members to collaborate.   

The main purpose of the conformance module will be to allow validation of
messages against static profiles during live message processing (i.e. within
a clinical system or an interface engine).  A draft class diagram of the
larger validation model is attached, which shows several example rules,
including a ConformsToDeclaredProfiles rule (which is the part I think this
group may be interested in).

Is anyone interested in collaborating on this?  The project will clearly
benefit HAPI by adding important new functionality.  I think it will also
benefit the Conformance SIG by providing a freely available implementation
that complements the MWB, as well as practical experience that can be fed
back into future versions of the standard.  

On a related topic, a couple of other conformance-related projects have been
initiated within HAPI.  This past summer David Kong completed his
undergraduate thesis at Queens University working on a tool to verify that
one profile properly constrains another.  Also, starting this fall, a group
of senior students at Algonquin College is beginning a two-term project to
create a tool that will generate Java classes from message profiles.  The
Profile classes will decorate HAPI Message classes and enforce profile
constraints.  This will make it possible to program against a profile, which
will present a simpler API than the underlying message and enforce some of
the profile constraints at compile time.  A Profile object may also be a
good target for object persistence.  Please let me know if you would like
more information on either of these projects.  

Thanks, 
Bryan 


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



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] cconference call

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

Hello hapiFolks,

I have Alex Harvey, Leslie Mann, Bryan Tripp, John Waldron and myself
confirmed for the hapi/jms conference call, is there anybody else joining ?
(the conference will take place today, starting at 3pm ET)

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.

[HAPI-devel] some additional thoughts about the hapi/jms project

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

First of all, the ideas you guys had been throwing in here are great, we are
definitely getting to a point of agreement and correctness! I just want to
add some comments about the proposed strategies.

1. I really like the idea where only the application the message was address
to, will be sending a response (and the fact that the bridge will be filling
the required header fields if they were not available, as the bridge knows
who is the sending legacy application). But I'd like to elaborate a little
bit more on this respect, to cover the special case where the "unsolicited
messages" have no destination, they are meant to be broadcasted into the
hapi/jms cloud. In this case there will be no designated receiving app, so
the bridge will just post the message (as a broadcast) to the topic, and
will send an ack back to the legacy app (being this a configurable
behavior).

2. The choice of the single topic, brings simplicity to the design of our
app, but it could create a bottle neck, as the MOM will have to process
every message (and execute a query on it) to find out its destinations. I
think that we could mitigate this potential problem, if we at least have two
topics, one for requests and another for responses.

Those are the only comments I have, I definitely think that we are in great
shape to come up with detailed uses cases of the hapi/jms, and start doing
some coding ;) -- actually a class diagram describing the whole idea, will
be very helpful to before start throwing some code in --

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.

[HAPI-devel] JMS HL7 addressing mechansim

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

I've been thinking more about how the bridge could use message properties to
generate HL7 responses and have come up with a few ideas that seem
interesting. Below are some rough ideas about how the mechanism could work.

Based on my understanding that HL7 messages are point to point I see two
kinds of applications using JMS: "legacy" point to point apps and "JMS-Hapi"
apps that could be point to point, multicast, or broadcast. Examples: a
point to point app could be an order entry system to a lab system and a
broadcast app could be a distributed EHR system that needs to query all
connected systems (can't think of a multicast example). These could all be
supported with appropriate message properties, a response filter mechanism
in the bridge, a single JMS topic, and multiple bridge sessions with the
topic. Topic sessions would be JMS_Inbound (all HL7 messages received from a
HL7 source), JMS_Outbound (all HL7 messages selected from the JMS topic),
and multiple? JMS_HL7_Outbound (only HL7 response messages). Note that JMS
subscribers can use a "NoLocal" attribute to inhibit the delivery of
messages published by its own connection.

All inbound HL7 messages passing through a bridge would have the HL7
destination and the messaging mode (PTP, multicast, broadcast) set as some
of the message properties of the corresponding JMS message.  If a response
is expected, once the message has been successfully published to the
JMS-Hapi topic via the JMS_Inbound session the originating bridge will setup
a JMS_HL7_Outbound reply topic session with a selection of JMSCorrelationID
= JMSMessageID of the just sent message.

Any connected bridge would be able to retrieve the message via JMS message
selectors on it's JMS_Outbound session and pass it on to it's connected HL7
system.  If a reponse is generated by the connected HL7 system the bridge's
response filtering mechanism would determine whether an HL7 response should
be forwarded to the originating bridge: PTP - bridge's HL7 application and
facility must match message's destination application and facility,
multicast - bridges HL7 application must match message's destination
application, and broadcast - just forward all responses.  If the filtering
mechanism determines that a HL7 response is needed then the original
message's JMSMessageID would be entered into the reponse message's
JMSCorrelationID field otherwise the field will be left empty. All responses
are published to the JMS-Hapi topic via the JMS_Outbond session.  Again, any
bridge with an appropriate selector would be able to retrieve the response
message but the originating bridge's reply topic subscription,
JMS_HL7_Outbound, will receive only those messages destined for it's
connected HL7 application based on selection of matching JMSCOrrelationID's
and these response messages would then be the only ones sent out to the HL7
app.

Some advantages that I see for such a mechanism:
1)  The ability to query all connected systems, be they "legacy" or
"JMS-Hapi", without any knowledge of the HL7 system topology. I can simply
address my single JMS message as broadcast and then wait for a response from
all the connected systems that select and receive my message.  

2)  All messages, whether query or response, use a single topic and can be
selected by a connected bridge (if a query is of interest, may not the reply
be as well?)

Disadvantages:
1)  Need to have more complicated bridge to handle reply filter mechanism

Any comments?

Leslie

RE: [HAPI-devel] new validation model

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

Hi Bryan,

Yep, I agree with you. Taking an hybrid aproach is best choice. That way we
are leveraging all the resources we have available. (And using each one
where it fits best)

alex6

-----Original Message-----
From: Tripp, Bryan
To: Guevara, Alexei; 'hl7...@li...'
Sent: 10/11/2002 2:43 PM
Subject: RE: [HAPI-devel] new validation model

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.