hl7api-devel — developer list

[HAPI-devel] RE: PipeParser addition for message types that do not specify a v alue for MSH9-2 (event trigger)

[Shrock, C. <Sh...@in...>]

In particular, Meditech.

-----Original Message-----
From: Shrock, Court 
Sent: Saturday, January 15, 2005 1:51 PM
To: 'hl7...@li...'
Subject: PipeParser addition for message types that do not specify a value
for MSH9-2 (event trigger)


I modified PipeParser.getMessageStructure so as to return the non-null value
of MSH9 in the case that it is the only value in the message.  I thought
someone might be interested that there are systems out there that require
this :)


Added just before the exception string is created:

<snip/>

} else if (comps.length == 1 && comps[0] != null) {
    messageStructure = comps[0];
}

<snip/>

[HAPI-devel] PipeParser addition for message types that do not specify a value for MSH9-2 (event trigger)

[Shrock, C. <Sh...@in...>]

I modified PipeParser.getMessageStructure so as to return the non-null value
of MSH9 in the case that it is the only value in the message.  I thought
someone might be interested that there are systems out there that require
this :)


Added just before the exception string is created:

<snip/>

} else if (comps.length == 1 && comps[0] != null) {
    messageStructure = comps[0];
}

<snip/>

RE: [HAPI-devel] Z-segments

[Shrock, C. <Sh...@in...>]

You will find the start of the trail in the model/v24/message/ADR_A19 class
constructor.  Notice how segments and groups are added by calling
this.add(MSH.class, b_required, b_repeating)?  Either add a line that adds
your custom Z segment to the base message or to whichever group it belongs.
If you want to add to the base message, add something like the following
just under the this.add(DSC.class) line:

this.add(Z.class, true, false);


Hope this helps....I actually just ran into a system (Meditech) that says it
is outputting hl7v2.2, but contains an RDE message type in MSH9 with no
event trigger value which isn't in v.2.2 and isn't valid anyway in v2.3
because of the missing event trigger component.  I ended up creating my own
AbstractMessage extended class to handle this message type.

-----Original Message-----
From: Daniel Nebot [mailto:dan...@ya...] 
Sent: Thursday, January 13, 2005 7:38 AM
To: hl7...@li...
Subject: [HAPI-devel] Z-segments


I am new to HAPI and am trying to parse an incoming pipe-formatted ADR_A19
response which includes an extra custom Z segment. Unfortunatelly, as far as
I see the PipeParser seems to ignore the Z segment and I cannot find it on
the resulting Message object.

I would be very grateful if somebody could post an example of how to manage
Z-messages and additional Z-segments in messages with HAPI.

Thanks
Dani

MSH|^~\&|sendApp|sendingFacility|rcvIngApp|rcvingFacility|200501101922||
MSH|^^ADR_A19|FAKEMSGID|P|2.4
PID|||||GRIJANDER^DANIEL|GARCIA||M|||&Sol i
Padris,120^^SABADELL^^08205^^CALLE||||||||||||BARCELONA
PD1|||||||||||E|Y
PV1||N
ZNB|DIA1^DOSIS1|DIA2^DOSIS2|DIA3^DOSIS3



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE
limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE --
well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

[HAPI-devel] Z-segments

[Daniel N. <dan...@ya...>]

I am new to HAPI and am trying to parse an incoming pipe-formatted
ADR_A19 response which includes an extra custom Z segment.
Unfortunatelly, as far as I see the PipeParser seems to ignore the Z
segment and I cannot find it on the resulting Message object.

I would be very grateful if somebody could post an example of how to
manage Z-messages and additional Z-segments in messages with HAPI.

Thanks
Dani

MSH|^~\&|sendApp|sendingFacility|rcvIngApp|rcvingFacility|200501101922||^^ADR_A19|FAKEMSGID|P|2.4
PID|||||GRIJANDER^DANIEL|GARCIA||M|||&Sol i
Padris,120^^SABADELL^^08205^^CALLE||||||||||||BARCELONA
PD1|||||||||||E|Y
PV1||N
ZNB|DIA1^DOSIS1|DIA2^DOSIS2|DIA3^DOSIS3

[HAPI-devel] HAPI 0.42

[Ed <eds...@wd...>]

When trying to Parse a file using HAPI 0.4.2 Test Panel, I receive the
following:

Java.lang.ClassCastExcxeption trying to set data type of OBX-5.

Here is the file:
MSH|^~\&|COSTELLO|ORCHARD
SOFTWARE|MEGAREG|UABHOSPC|20040221112417||ORU^R01|325|P|2.1
PID|1|3566|3566||SUNLIGHT^CREE||19790701|F|||14987 Pixie Pt
Cir^^Naperville^IL^00000||||||||
OBR|1|27102|58|CMETABOLIC^CMetabol|R||20040221112415|||^Bahamonde^Toodie
||||200402211124||D1^Welby^Marcus||||||200402211124|||F||||||||||
OBX|1|NM|2823-3^K+||3.3|MMOL/L|3.5-5.5||||F

As you can see, OBX-2 states that it is a Numeric data type.  OBX-5 is
3.3, which is a Numeric data type.
Can you tell me what is wrong?

Ed Salvador Jr.
WD Net, Inc.

RE: RE : [HAPI-devel] I can't have log with debug level

[Shrock, C. <Sh...@in...>]

Are you sure that the log4j.xml file that you are editing is the one =
that is
being loaded?  There is a commanline parameter that throws log4j to be
verbose about where it is getting the config file from, but I don't =
remember
the specifics.

-----Original Message-----
From: THIBAULT Joseph [mailto:jos...@si...]=20
Sent: Friday, January 07, 2005 9:10 AM
To: hl7...@li...
Subject: RE : [HAPI-devel] I can't have log with debug level


I have only error log.

-----Message d'origine-----
De : hl7...@li...
[mailto:hl7...@li...] De la part de Shrock,
Court
Envoy=E9 : vendredi 7 janvier 2005 17:57
=C0 : hl7...@li...
Objet : RE: [HAPI-devel] I can't have log with debug level


Are you getting any log output at all?

-----Original Message-----
From: THIBAULT Joseph [mailto:jos...@si...]=20
Sent: Friday, January 07, 2005 6:16 AM
To: hl7...@li...
Subject: [HAPI-devel] I can't have log with debug level


I try to change the file log4j.xml but even if I put DEBUG in place of =
INFO,
I don't have debug log.=20
I don't understand why.
=20
Joseph

RE: [HAPI-devel] I can't have log with debug level

[Shrock, C. <Sh...@in...>]

Are you getting any log output at all?

-----Original Message-----
From: THIBAULT Joseph [mailto:jos...@si...] 
Sent: Friday, January 07, 2005 6:16 AM
To: hl7...@li...
Subject: [HAPI-devel] I can't have log with debug level


I try to change the file log4j.xml but even if I put DEBUG in place of INFO,
I don't have debug log. 
I don't understand why.
 
Joseph

RE: [HAPI-devel] Connection receipts HashMap grows without bound?

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

Hi Dan,=20

I think you're right.  Thanks very much for pointing this out.  I don't
understand why this didn't cause more obvious problems.  Maybe people =
have
been recycling Connections to avoid it.  In any case, I've made the =
change
you suggested. =20

Best regards,=20
Bryan=20

-----Original Message-----
From: hl7...@li... on behalf of Dan =
Hollacher
Sent: Mon 1/3/2005 5:01 PM
To: hl7...@li...
Subject: [HAPI-devel] Connection receipts HashMap grows without bound?
=20
This may be a foolish question -- but I don't see where
a MessageReceipt is ever remove() d from the receipts HashMap.
=20
What am I missing ?
=20
Modifiying the findRecipient to use remove() on the
HashMap would still return the MessageReceipt
requested -- and I only see it being used in Receiver.
=20
respects,
=20
d.

[HAPI-devel] Connection receipts HashMap grows without bound?

[Dan H. <dho...@ri...>]

This may be a foolish question -- but I don't see where
a MessageReceipt is ever remove() d from the receipts HashMap.
=20
What am I missing ?
=20
Modifiying the findRecipient to use remove() on the
HashMap would still return the MessageReceipt
requested -- and I only see it being used in Receiver.
=20
respects,
=20
d.

RE: [HAPI-devel] Feature request to aid in de-identification

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

Sanidas, Nicholas S. wrote:

> I am currently rolling my own capability to de-identify ADT records.=20
> Typically, for bio-surveillance applications, only a small subset of =
ADT=20
> A04/A08 segment fields/components are required for analysis.
>=20
> What would be handy is for a capability to set a list of segment=20
> field/component masks (sort of like one does for =
PreParser.getFields())=20
> that could be uses to create a pass thru filter of what fields should=20
> make in thru during a message transformation process. If the mask =
syntax=20
> could support a way to extract an entire field (including all of its=20
> components/subcomponents) that would be nice as well.
>=20
> I am currently hacking thru a solution using PreParser and Terser with =
a=20
> generic message. The pass thru fields/components are in a properties =
file.
>=20
> I am interested to see if anybody else might find this type of feature =

> valuable. With HIPAA and the sensitivity of medical records, it seems=20
> like a quick and easy pass thru transformation might be a nice feature =

> to add to HAPI.

Another approach will be to enhance the HAPI parsed messages to support =
the
visitor patter. Making a HAPI message "visit-able" will make the task of
applying an algorithm to a message an easy one.

See http://www.javaworld.com/javaworld/javatips/jw-javatip98.html

Alexei

Re: [HAPI-devel] Feature request to aid in de-identification

[Archie C. <ar...@de...>]

Sanidas, Nicholas S. wrote:
> I am currently rolling my own capability to de-identify ADT records. 
> Typically, for bio-surveillance applications, only a small subset of ADT 
> A04/A08 segment fields/components are required for analysis.
> 
> What would be handy is for a capability to set a list of segment 
> field/component masks (sort of like one does for PreParser.getFields()) 
> that could be uses to create a pass thru filter of what fields should 
> make in thru during a message transformation process. If the mask syntax 
> could support a way to extract an entire field (including all of its 
> components/subcomponents) that would be nice as well.
> 
> I am currently hacking thru a solution using PreParser and Terser with a 
> generic message. The pass thru fields/components are in a properties file.
> 
> I am interested to see if anybody else might find this type of feature 
> valuable. With HIPAA and the sensitivity of medical records, it seems 
> like a quick and easy pass thru transformation might be a nice feature 
> to add to HAPI.

XSLT might be a nice and clean way to do this. I.e., your application would 
convert HL7 to XML, then run that through a simple XSLT transformation that 
would elide the fields you didn't want, then convert the XML result back into HL7.

Then your XSLT file becomes the "configuration" of the filter.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*

[HAPI-devel] Feature request to aid in de-identification

[Sanidas, N. S. <Nic...@jh...>]

Hello all,

I am currently rolling my own capability to de-identify ADT records.
Typically, for bio-surveillance applications, only a small subset of ADT
A04/A08 segment fields/components are required for analysis.

What would be handy is for a capability to set a list of segment
field/component masks (sort of like one does for PreParser.getFields())
that could be uses to create a pass thru filter of what fields should
make in thru during a message transformation process. If the mask syntax
could support a way to extract an entire field (including all of its
components/subcomponents) that would be nice as well.

I am currently hacking thru a solution using PreParser and Terser with a
generic message. The pass thru fields/components are in a properties
file.

I am interested to see if anybody else might find this type of feature
valuable. With HIPAA and the sensitivity of medical records, it seems
like a quick and easy pass thru transformation might be a nice feature
to add to HAPI.

And to the HAPI development team, excellent job and your labors are
highly appreciated!

Nick

Re: [HAPI-devel] ADT^A13 bad parse

[Archie C. <ar...@de...>]

Tripp, Bryan wrote:
>>This would fine with me, but it doesn't seem like this is what HAPI
>>currently does. Instead, at least in the example I saw, it put *all*
>>segements following the unknown segment at the end of the 
>>message. In my
>>example, the unkown segment caused the XML tags to get moved 
>>like this:
>>
>>   ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1
>>   ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1
>>   ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX
>>
>>In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown
>>segment but otherwise in their rightful places.
> 
> If you have an unexpected segment, it goes at the end of the current group
> (or end of the first subgroup reached), which is the only legal option.
> Then segments after it have to go after it, again the only legal option.
> HAPI won't re-order them.  

What exactly do you mean by "legal"? It seems like the message is already
illegal so trying to maintain any further legality is questionable... or
else I'm misunderstanding things.

I.e., I'm not sure it's worth messing up the legal segments just to make
room for an illegal one (from the point of view of the XML output structure).

> On second thought, maybe we should add another option to that previous list,
> i.e. quietly drop unexpected segments.  Would that help in your case, or did
> you want access to that PD1?  

In this particular case dropping it would have been fine, as we don't look at 
PD1 segements in ADT^A13 messages (yet). Of course in general that may not be
true. But the larget point is that ideally an unknown segment shouldn't
"mess up" the rest of the message.

I guess if the segment is unknown then just plain dropping it is a
very reasonable thing to do. It's hard to say what is always right
though, my experience with all the quirks of HL7 is limited.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*

RE: [HAPI-devel] ADT^A13 bad parse

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

Hi Archie,=20
=20
> This would fine with me, but it doesn't seem like this is what HAPI
> currently does. Instead, at least in the example I saw, it put *all*
> segements following the unknown segment at the end of the=20
> message. In my
> example, the unkown segment caused the XML tags to get moved=20
> like this:
>=20
>    ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1
>    ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1
>    ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX
>=20
> In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown
> segment but otherwise in their rightful places.

If you have an unexpected segment, it goes at the end of the current =
group
(or end of the first subgroup reached), which is the only legal option.
Then segments after it have to go after it, again the only legal option.
HAPI won't re-order them. =20

On second thought, maybe we should add another option to that previous =
list,
i.e. quietly drop unexpected segments.  Would that help in your case, or =
did
you want access to that PD1? =20

Bryan=20

Re: [HAPI-devel] ADT^A13 bad parse

[Archie C. <ar...@de...>]

Tripp, Bryan wrote:
> If I understand correctly, your suggestion was to look at later versions of
> the same message structure and switch versions if it looks like one of them
> matches better.  I'm not enthusiastic about this, because early adopters
> (even long after the fact ;) sometimes incorporate segments from later
> versions into their messages, and because I think that quietly correcting an
> error can lead to deeper confusion than either failing, or assuming there is
> no error and returning the literal result of the call. 

Actually I agree with you that trying a later version is not the best
idea.. it's the right thing to do sometimes but not always, so it shouldn't
be mandatory.

> Assuming we're in try-to-parse-everything mode, if a non-Z segment appears
> that is not expected anywhere in the message, HAPI will assume it's a legal
> local extension and put it at the end of the current group.  This approach
> can yield unexpected results, but only if there is an error in the message.

This would fine with me, but it doesn't seem like this is what HAPI
currently does. Instead, at least in the example I saw, it put *all*
segements following the unknown segment at the end of the message. In my
example, the unkown segment caused the XML tags to get moved like this:

   ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1
   ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1
   ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX

In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown
segment but otherwise in their rightful places.

> Another option would be to decorate a parser with something that guesses
> message structure and version.  I.e. something you would use like this: new
> VersionGuessingParserDecorator(new PipeParser()).  How does that sound to
> you?  

Something like that would be a better way to handle cases where people
wanted to do "guessing".. i.e., you'd have to explicitly ask for it.

I'd guess most people will eventually end up asking for it unfortunately :-)

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*

RE: [HAPI-devel] ADT^A13 bad parse

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

Hi Archie,=20

Assuming we're in try-to-parse-everything mode, if a non-Z segment =
appears
that is not expected anywhere in the message, HAPI will assume it's a =
legal
local extension and put it at the end of the current group.  This =
approach
can yield unexpected results, but only if there is an error in the =
message.


If I understand correctly, your suggestion was to look at later versions =
of
the same message structure and switch versions if it looks like one of =
them
matches better.  I'm not enthusiastic about this, because early adopters
(even long after the fact ;) sometimes incorporate segments from later
versions into their messages, and because I think that quietly =
correcting an
error can lead to deeper confusion than either failing, or assuming =
there is
no error and returning the literal result of the call. =20

Another option would be to decorate a parser with something that guesses
message structure and version.  I.e. something you would use like this: =
new
VersionGuessingParserDecorator(new PipeParser()).  How does that sound =
to
you? =20

Bryan=20


> -----Original Message-----
> From: hl7...@li...
> [mailto:hl7...@li...]On Behalf Of Archie
> Cobbs
> Sent: December 15, 2004 3:28 PM
> To: Tripp, Bryan
> Cc: hl7...@li...
> Subject: Re: [HAPI-devel] ADT^A13 bad parse
>=20
>=20
> Tripp, Bryan wrote:
> > That's how HAPI was first implemented actually, and I agree=20
> it's the=20
> > safest.  It was changed because there were several complaints from=20
> > people who use non-standard messages, and because the HL7=20
> spec says that=20
> > unexpected segments are to be ignored (presumably so that compliant=20
> > processors don't choke on messages with local additions). =20
> How about=20
> > making this a configurable option in HAPI 0.5, i.e. the=20
> options would be:=20
> > =20
> > 1) Fail if there are any unexpected segments
> > 2) Fail if there are any unexpected non-Z segments=20
> > 3) Fail if any required segments are missing=20
> > 4) Try to parse everything =20
>=20
> That would be nice... my question though is whether the heuristic
> for option #4 can be improved to handle an unknown non-Z segment
> in the middle of a message. What it does now is not quite right.
>=20
> Thanks,
> -Archie
>=20
> ______________________________________________________________
> ____________
> Archie Cobbs      *        CTO, Awarix        *     =20
> http://www.awarix.com
>=20
>=20
> *
> Confidentiality Notice: This e-mail message, including any=20
> attachments, is for the sole use of the intended recipient(s)=20
> and may contain confidential and privileged information. Any=20
> unauthorized review, use, disclosure or distribution is=20
> prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and=20
> destroy all copies of the original message.
> *
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>=20

Re: [HAPI-devel] ADT^A13 bad parse

[Archie C. <ar...@de...>]

Tripp, Bryan wrote:
> That's how HAPI was first implemented actually, and I agree it's the 
> safest.  It was changed because there were several complaints from 
> people who use non-standard messages, and because the HL7 spec says that 
> unexpected segments are to be ignored (presumably so that compliant 
> processors don't choke on messages with local additions).  How about 
> making this a configurable option in HAPI 0.5, i.e. the options would be: 
>  
> 1) Fail if there are any unexpected segments
> 2) Fail if there are any unexpected non-Z segments 
> 3) Fail if any required segments are missing 
> 4) Try to parse everything  

That would be nice... my question though is whether the heuristic
for option #4 can be improved to handle an unknown non-Z segment
in the middle of a message. What it does now is not quite right.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*

Re: [HAPI-devel] using hapi do develop integration in the HIS

[Steve H. <ste...@gm...>]

Dario,

You should be able to see verbose log output (including messages
received) if logging is properly configured.

Handling of incoming HL7 messages is done by "Applications," which
must be registered with the server.  By default, SimpleServer (which I
assume you're using) starts up with no registered Applications.  You
will need to create one by implementing the Application interface and
then register it with your instance of SimpleServer.  You might call
it "ForwardingApplication" or something.  There are 2 methods to
implement:  canProcess() and processMessage().  I think your
Application's canProcess() will always return true.

Good luck.


-Steve


On Wed, 15 Dec 2004 16:45:55 +0100, monaldi
<dar...@os...> wrote:
> Oi!
> 
> I am an italian student who is developing a project about integration with
> medtrak and some custom applications developed for the hospital here, using
> HL7. I would like to use HAPI to test the message exchange between our
> actors. Basically i would like to use hapi like an intermediate
> message-forwarding layer between the two actors. I cant find a way to:
> 
> 1- make HAPI show the messages it receives no the incoming port, other than
> ACK messages.
> 2- make HAPI forward the messages to another application/port. It always
> tells me that ' No appropriate destination could be found to which this
> message could be routed.. '
> 
> in fact, for now, i would like hapi to receive on an incoming port, then
> forward to an outgoing port, which is the port on whic MESA is listening.
> 
> Can you help me or at least help me find some documentation i could fin tips
> on?
> 
> Many thanx,
> bye,
> 
> Dario Feola,
> Azienda Ospedaliera V. Monaldi - Napoli - ITALY
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.5.3 - Release Date: 14/12/2004
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

RE: [HAPI-devel] using hapi do develop integration in the HIS

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

Hi,=20

Have a look at the package ca.uhn.hl7v2.protocol in CVS.  It's better at
that kind of thing than the current release is.  You want a
ca.uhn.hl7v2.protocol.impl.HL7Server.  It uses a
ca.uhn.hl7v2.protocol.ApplicationRouter that routes message types to
ca.uhn.hl7v2.Application instances.  You need to implement Application.
Your implementation should use a =
ca.uhn.hl7v2.protocol.impl.InitiatorImpl to
forward messages to your destination.  That's a little more work than it
should be, but that's because message routing isn't really in HAPI's =
scope
(the routing code is just there to simplify getting messages to the =
right
code within a system).   =20

Bryan=20

> -----Original Message-----
> From: hl7...@li...=20
> [mailto:hl7...@li...]On Behalf Of monaldi
> Sent: December 15, 2004 10:46 AM
> To: hl7...@li...
> Subject: [HAPI-devel] using hapi do develop integration in the HIS
>=20
>=20
> Oi!
>=20
> I am an italian student who is developing a project about=20
> integration with
> medtrak and some custom applications developed for the=20
> hospital here, using
> HL7. I would like to use HAPI to test the message exchange between our
> actors. Basically i would like to use hapi like an intermediate
> message-forwarding layer between the two actors. I cant find a way to:
>=20
> 1- make HAPI show the messages it receives no the incoming=20
> port, other than
> ACK messages.
> 2- make HAPI forward the messages to another=20
> application/port. It always
> tells me that ' No appropriate destination could be found to=20
> which this
> message could be routed.. '
>=20
> in fact, for now, i would like hapi to receive on an incoming=20
> port, then
> forward to an outgoing port, which is the port on whic MESA=20
> is listening.
>=20
> Can you help me or at least help me find some documentation i=20
> could fin tips
> on?
>=20
> Many thanx,
> bye,
>=20
> Dario Feola,=20
> Azienda Ospedaliera V. Monaldi - Napoli - ITALY
>=20
> --=20
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.5.3 - Release Date: 14/12/2004
> =20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>=20

[HAPI-devel] using hapi do develop integration in the HIS

[monaldi <dar...@os...>]

Oi!

I am an italian student who is developing a project about integration with
medtrak and some custom applications developed for the hospital here, using
HL7. I would like to use HAPI to test the message exchange between our
actors. Basically i would like to use hapi like an intermediate
message-forwarding layer between the two actors. I cant find a way to:

1- make HAPI show the messages it receives no the incoming port, other than
ACK messages.
2- make HAPI forward the messages to another application/port. It always
tells me that ' No appropriate destination could be found to which this
message could be routed.. '

in fact, for now, i would like hapi to receive on an incoming port, then
forward to an outgoing port, which is the port on whic MESA is listening.

Can you help me or at least help me find some documentation i could fin tips
on?

Many thanx,
bye,

Dario Feola, 
Azienda Ospedaliera V. Monaldi - Napoli - ITALY

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.5.3 - Release Date: 14/12/2004
 

RE: RE: [HAPI-devel] ADT^A13 bad parse

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

Hi Nico,=20
=20
That's how HAPI was first implemented actually, and I agree it's the =
safest.
It was changed because there were several complaints from people who use
non-standard messages, and because the HL7 spec says that unexpected
segments are to be ignored (presumably so that compliant processors =
don't
choke on messages with local additions).  How about making this a
configurable option in HAPI 0.5, i.e. the options would be:=20
=20
1) Fail if there are any unexpected segments
2) Fail if there are any unexpected non-Z segments=20
3) Fail if any required segments are missing=20
4) Try to parse everything =20
=20
Bryan=20

-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of
ni...@sk...
Sent: December 14, 2004 2:10 PM
To: Sh...@in...; hl7...@li...
Subject: RE: RE: [HAPI-devel] ADT^A13 bad parse


Hi,
=20
My opinion on this is that HAPI should be able to detect non-standard
segments in a message structure (eg the PD1 segment that is not allowed =
in
2.2 ADT) an stop parsing when these kind of errors are encountered.
=20
If customisation is required Z-segments, or custom messagestructures =
should
be used. Hapi should not block processing of course when a Z-segment is
encountered.
=20
I think that this makes sense because if you don't follow "the rules" =
one
day you'll come accross an application which has to process your =
"modified"
message that won't be able to process your message and reject the =
message.
=20
Best Regards
=20
Nico



  _____ =20


I have run into the same thing. After digging further, I have realized =
that
at my company, the HL7 specification has been modified at will in many
different places. The result is that I must create my own modified model
implementation to match the structure of the messages that I end up =
seeing.=20

Cheers,
Court

-----Original Message-----
From: Archie Cobbs [mailto:ar...@de...]=20
Sent: Monday, December 13, 2004 2:00 PM
To: hl7...@li...
Subject: [HAPI-devel] ADT^A13 bad parse



We received an ADT^A13 message that has "2.2" in the MSH.12 field, but
contained these segments: MSH EVN PID PD1 NK1 PV1 PV2 OBX AL1 DG1 DG1 =
GT1
IN1 IN2 ..

Note that the ability to include the "PD1" segment was added in 2.3. So
technically this is a bogus message because it says "2.2" but has a PD1
segment (right?).

In any case, HAPI happily parses this message but the resulting XML =
contains
inform! ation in the wrong places, etc. For example, the PV1.3 =
information
ends up in ADT_A13.IN1IN2IN3/NK1/NK1.40.

So although it's nice that HAPI handles this message at all, it seems =
like
it doesn't do so very gracefully. Is this the intended behavior?

Could HAPI be configured to try a later version of the spec if the =
message
doesn't parse correctly, instead of putting things in the wrong field? =
It
seems like in practice the MSH.12 field is sometimes just more of a hint
than reality.

Thanks,
-Archie

_________________________________________________________________________=
_
Archie Cobbs * CTO, Awarix * http://www.awarix.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Re: [HAPI-devel] ADT^A13 bad parse

[Archie C. <ar...@de...>]

Tripp, Bryan wrote:
> HAPI indeed won't give you what you want if the message doesn't have the
> core structure that it declares in MSH-9, which is fine (and I think
> unavoidable), but I agree that it should try to fail in that case.  It's
> hard to tell legal local additions from a structural problem ... the only
> way I can think to do this is to fail if the resulting message is missing
> required segments.  If you can think of a better way please let me know.

Yes, this definitely seems like a hard problem to get right in every case.

In this particular case, the message contained an unexpected (and unknown)
segment (PD1). HAPI tries to parse the message anyway, which is good, but
I'm not sure I understand how the PD1 segment ended up where it did (after 
ADT_A13.IN1IN2IN3/IN3) and why it caused NK1, PV1, PV2, OBX, etc to all
be skipped and added later in the wrong place.

Although getting it "right" is all cases is probably impossible, it seems
like the case of an "extra" unexpected segment is probably a common one
and maybe the parse recovery strategy should have a special case for it.. ?

> But are you saying that a PV1 got parsed into an NK1?  That would be a bug
> that I don't know about.

The PV1 parsed as NK1 was my fault, due to a cut & paste problem
when pasting the HL7 into the HAPI tester Swing app (extra line breaks
were introduced due to screen wrap).

What actually happens is that the PV1 XML tag gets put inside the
ADT_A13.IN1IN2IN3 tag, after the NK1 tag (along with OBX, etc.).
Sorry for the misinformation.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*

RE: RE: [HAPI-devel] ADT^A13 bad parse

[<ni...@sk...>]

Hi,

My opinion on this is that HAPI should be able to detect non-standard segments in a message structure (eg the PD1 segment that is not allowed in 2.2 ADT) an stop parsing when these kind of errors are encountered.

If customisation is required Z-segments, or custom messagestructures should be used. Hapi should not block processing of course when a Z-segment is encountered.

I think that this makes sense because if you don't follow \"the rules\" one day you'll come accross an application which has to process your \"modified\" message that won't be able to process your message and reject the message.

Best Regards

Nico





I have run into the same thing. After digging further, I have realized that
at my company, the HL7 specification has been modified at will in many
different places. The result is that I must create my own modified model
implementation to match the structure of the messages that I end up seeing. 

Cheers,
Court

-----Original Message-----
From: Archie Cobbs [mailto:ar...@de...] 
Sent: Monday, December 13, 2004 2:00 PM
To: hl7...@li...
Subject: [HAPI-devel] ADT^A13 bad parse



We received an ADT^A13 message that has \"2.2\" in the MSH.12 field, but
contained these segments: MSH EVN PID PD1 NK1 PV1 PV2 OBX AL1 DG1 DG1 GT1
IN1 IN2 ..

Note that the ability to include the \"PD1\" segment was added in 2.3. So
technically this is a bogus message because it says \"2.2\" but has a PD1
segment (right?).

In any case, HAPI happily parses this message but the resulting XML contains
information in the wrong places, etc. For example, the PV1.3 information
ends up in ADT_A13.IN1IN2IN3/NK1/NK1.40.

So although it's nice that HAPI handles this message at all, it seems like
it doesn't do so very gracefully. Is this the intended behavior?

Could HAPI be configured to try a later version of the spec if the message
doesn't parse correctly, instead of putting things in the wrong field? It
seems like in practice the MSH.12 field is sometimes just more of a hint
than reality.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

RE: [HAPI-devel] ADT^A13 bad parse

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

Hi Archie,=20

HAPI indeed won't give you what you want if the message doesn't have the
core structure that it declares in MSH-9, which is fine (and I think
unavoidable), but I agree that it should try to fail in that case.  It's
hard to tell legal local additions from a structural problem ... the =
only
way I can think to do this is to fail if the resulting message is =
missing
required segments.  If you can think of a better way please let me know.


But are you saying that a PV1 got parsed into an NK1?  That would be a =
bug
that I don't know about. =20

Thanks,=20
Bryan=20

> -----Original Message-----
> From: hl7...@li...
> [mailto:hl7...@li...]On Behalf Of Archie
> Cobbs
> Sent: December 13, 2004 5:00 PM
> To: hl7...@li...
> Subject: [HAPI-devel] ADT^A13 bad parse
>=20
>=20
>=20
> We received an ADT^A13 message that has "2.2" in the MSH.12 field,
> but contained these segments: MSH EVN PID PD1 NK1 PV1 PV2 OBX AL1
> DG1 DG1 GT1 IN1 IN2 ..
>=20
> Note that the ability to include the "PD1" segment was added in 2.3.
> So technically this is a bogus message because it says "2.2" but has
> a PD1 segment (right?).
>=20
> In any case, HAPI happily parses this message but the resulting XML
> contains information in the wrong places, etc. For example, the PV1.3
> information ends up in ADT_A13.IN1IN2IN3/NK1/NK1.40.
>=20
> So although it's nice that HAPI handles this message at all, it seems
> like it doesn't do so very gracefully. Is this the intended behavior?
>=20
> Could HAPI be configured to try a later version of the spec if the
> message doesn't parse correctly, instead of putting things in the
> wrong field? It seems like in practice the MSH.12 field is sometimes
> just more of a hint than reality.
>=20
> Thanks,
> -Archie
>=20
> ______________________________________________________________
> ____________
> Archie Cobbs      *        CTO, Awarix        *     =20
http://www.awarix.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

RE: [HAPI-devel] RE: javabean compliant get/set pairs

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

Hi Jim,=20

Thank you, that's a good suggestion.  It's good to have each parent as =
the
factory of its own children, but I don't think adding setters that =
override
this behaviour would cause any problems.  =20

If anyone else has an opinion about this, your comments would be
appreciated.=20

Thanks,=20
Bryan=20

> -----Original Message-----
> From: hl7...@li...
> [mailto:hl7...@li...]On Behalf Of Jim
> Krygowski
> Sent: December 13, 2004 9:40 AM
> To: hl7...@li...
> Subject: [HAPI-devel] RE: javabean compliant get/set pairs
>=20
>=20
> Hey-
>=20
> Sorry about the typos in the code example.... I haven't had=20
> enough coffee=20
> yet.
>=20
> The example should have read:
>=20
> public MSH getMSH(); // simple getter
> public void setMSH(MSH value); // simple setter
>=20
> public void=20
> setORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI(int index,=20
> ORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI value); // indexed setter
> public ORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI
> getORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI(int index); // indexed
> getter
>=20
> public void
>=20
> setORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI(ORU_R01_PIDPD1
> NK1NTEPV1PV2ORCOBRNTEOBXNTECTI
>=20
> [] value); // array setter
> public ORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI[]
> getORU_R01_PIDPD1NK1NTEPV1PV2ORCOBRNTEOBXNTECTI(); // array getter
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>=20