hl7api-devel — developer list

[HAPI-devel] Hi

[latha <la...@re...>]

 =20
Hi,

    I am Latha V working as a Software Engineer for reli e-marg Mysore. =
We are developing an application which is using HL7 standard. We are =
using the recent HAPI which we got it from sourceforge.net i.e =
hapi-0.5beta.jar. We are working on 2.5 version of HL7. In the recent =
jar what we are using, we are unable to find the class files for some of =
the events of 2.5 version. The events are as follows..

ADT_A04

ADT_A08

ADT_A23

ADT_A29

ADT_A31

PMU_B02

PPR_PC2

PPR_PC3

REF_I13

REF_I14

SRM_S02

SRM_S03

SRM_S04

SRM_S05

SRM_S09

So, can you please let me know where can i find the jar which contains =
the class files for these events?





Thanks & Regards=20

Latha V

Re: [HAPI-devel] HL7 v2 Database

[Bryan T. <bp...@gm...>]

Hi Peter,=20

HL7 sells the database at their online store. It's a commercial
product of HL7 Germany, and not cheap to buy. HAPI has special
permission to release work derived from the DB contents.

Bryan=20

On 8/29/05, Peter Murray <pet...@gm...> wrote:
> Hello,
>=20
> From the HAPI docs, I noticed that HAPI generates the version specific
> classes from an HL7 database.  I was wondering how HAPI got a hold of
> this database and if it's available (to HL7 members).  The only
> versions of the standards I can find are the Word documents.
>=20
> Thank you,
>=20
> Peter
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

[HAPI-devel] HL7 v2 Database

[Peter M. <pet...@gm...>]

Hello,

From the HAPI docs, I noticed that HAPI generates the version specific
classes from an HL7 database.  I was wondering how HAPI got a hold of
this database and if it's available (to HL7 members).  The only
versions of the standards I can find are the Word documents.

Thank you,=20

Peter

Re: [HAPI-devel] Validation of HL7 message

[Bryan T. <bp...@gm...>]

Hi David,=20

I'm not sure this can be done with conformance profiles, unless you
are expecting a constant number of columns (e.g. always 4).

If you used HAPI 0.5, you could easily do this with a MessageRule. You
would implement ca.uhn.hl7v2.validation.MessageRule to check this
constraint and produce a ValidationException if it isn't met. You
would then have to tell your parser to apply this rule, using
Parser.setValidationContext(). The argument to this method is a
ca.uhn.hl7v2.validation.ValidationContext. See
ca.uhn.hl7v2.validation.impl.DefaultValidationContext for an example.

Bryan=20

On 8/23/05, Empey, David (EDS) <Dav...@me...> wrote:
> I want to do a validation of a message like the following:
> =20
> MSH^~|\&^DTS Term Srv~~L^200V^XUMF
> MFS^T10^20050809154913.903-0600^^MFN~M01~MFN_M01^11236205539030^P^2.4^^^A=
L^AL^USA
> MFI^med.term.maintenance.GMRVVitalType~GMRV Vital
> Type~ERT^^UPD^20050809154913.903-0600^20050809154913.903-0600^NE
> MFE^MUP^^20050809154913.903-0600^4688718~AUDIOMETRY~ERT~AUDIOMETRY~AUDIOM=
ETRY~VA^CE
> RDF^2^vuid~NM~20|name~ST~50=20
> RDT^4688718^AUDIOMETRY=20
> MFE^MUP^^20050809154913.903-0600^4500634~BLOOD
> PRESSURE~ERT~BLOOD PRESSURE~BLOOD PRESSURE~VA^CE=20
> RDF^2^vuid~NM~20|name~ST~50
> RDT^4500634^BLOOD PRESSURE=20
> MFE^MUP^^20050809154913.903-0600^4688719~CENTRAL VENOUS
> PRESSURE~ERT~CENTRAL VENOUS PRESSURE~CENTRAL VENOUS PRESSURE~VA^CE=20
> RDF^2^vuid~NM~20|name~ST~50
> RDT^4688719^CENTRAL VENOUS PRESSURE
> =20
> Specifically, I want to use the HAPI 0.4.2 library to validate the RDF an=
d
> RDT segments to assure the number of columns in RDF matches the number of
> columns in RDT.  I've looked at using DefaultValidator and I've looked at
> using ProfileTestApplication but I can't get either to work.  Maybe I'm
> going about validation wrong.  Can you help me?
> =20
> Thanks
> =20
> =20
> =20
>=20
>=20
> David Empey
>=20
> Salt Lake OIFO
>=20
> 550 Foothill Drive
>=20
> Suite 400
>=20
> Salt Lake City, UT  84113
>=20
> =20
>=20
> ( phone: 801-588-5226
>=20
> + mailto:dav...@me...
>=20
> www.eds.com
>=20
> =20
>

[HAPI-devel] Validation of HL7 message

[Empey, D. \(EDS\) <Dav...@me...>]

I want to do a validation of a message like the following:
=20
MSH^~|\&^DTS Term Srv~~L^200V^XUMF
MFS^T10^20050809154913.903-0600^^MFN~M01~MFN_M01^11236205539030^P^2.4^^^
AL^AL^USA=20
MFI^med.term.maintenance.GMRVVitalType~GMRV Vital
Type~ERT^^UPD^20050809154913.903-0600^20050809154913.903-0600^NE=20
MFE^MUP^^20050809154913.903-0600^4688718~AUDIOMETRY~ERT~AUDIOMETRY~AUDIO
METRY~VA^CE=20
RDF^2^vuid~NM~20|name~ST~50=20
RDT^4688718^AUDIOMETRY=20
MFE^MUP^^20050809154913.903-0600^4500634~BLOOD PRESSURE~ERT~BLOOD
PRESSURE~BLOOD PRESSURE~VA^CE=20
RDF^2^vuid~NM~20|name~ST~50
RDT^4500634^BLOOD PRESSURE=20
MFE^MUP^^20050809154913.903-0600^4688719~CENTRAL VENOUS
PRESSURE~ERT~CENTRAL VENOUS PRESSURE~CENTRAL VENOUS PRESSURE~VA^CE=20
RDF^2^vuid~NM~20|name~ST~50
RDT^4688719^CENTRAL VENOUS PRESSURE
=20
Specifically, I want to use the HAPI 0.4.2 library to validate the RDF
and RDT segments to assure the number of columns in RDF matches the
number of columns in RDT.  I've looked at using DefaultValidator and
I've looked at using ProfileTestApplication but I can't get either to
work.  Maybe I'm going about validation wrong.  Can you help me?
=20
Thanks
=20
=20
=20
David Empey

Salt Lake OIFO

550 Foothill Drive

Suite 400

Salt Lake City, UT  84113

=20

( phone: 801-588-5226

+ mailto:dav...@me...

www.eds.com
<file:///C:/Documents%20and%20Settings/vhaislempeyd/Application%20Data/M
icrosoft/Signatures/www.eds.com>=20

=20

=20

Re: [HAPI-devel] Terser Issue

[Bryan T. <bp...@gm...>]

Hi Terry,=20

Sorry, the examples should be updated to reflect the new syntax. Try this .=
..=20

String in1_3 =3D terser.get("/.INSURANCE(0)/IN1-3");

Bryan=20


On 8/10/05, Waldron, Terry <wal...@kg...> wrote:
> Hi,
>=20
> I'm trying to work with the 0.5 beta using the terser. With the 4.3 versi=
on I could use the code:
>=20
> String in1_3 =3D terser.get("/ADT_A01_IN1IN2IN3ROL(0)/IN1-3");
>=20
> to get the string value. When I do this with 0.5 beta on the same message=
, changing the group spec to ADT_A01_INSURANCE and adding a '.' so the code=
 looks like this:
>=20
> String in1_3 =3D terser.get("/.ADT_A01_INSURANCE(0)/IN1-3");
>=20
> I get the following error:
>=20
>=20
> ca.uhn.hl7v2.HL7Exception: End of message reached while iterating without=
 loop
>        at ca.uhn.hl7v2.util.MessageNavigator.iterate(MessageNavigator.jav=
a:242)
>        at ca.uhn.hl7v2.util.SegmentFinder.findStructure(SegmentFinder.jav=
a:83)
>        at ca.uhn.hl7v2.util.SegmentFinder.findGroup(SegmentFinder.java:71=
)
>        at ca.uhn.hl7v2.util.Terser.getSegment(Terser.java:224)
>        at ca.uhn.hl7v2.util.Terser.get(Terser.java:194)
>        at Test_Terser.main(Test_Terser.java:57)
>=20
> What am I missing here?
>=20
>=20
>=20
> Terry Waldron
> RMS Systems Analyst
> Information Management
> Kingston General Hospital
> 613 - 549 - 6666  ext. 3828
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

[HAPI-devel] Version 2.5 Issue

[Waldron, T. <wal...@KG...>]

Hi,=0D=0A=0D=0AADT A01 getINSURANCE(int) and getINSURANCEreps() is missing.=
 I am unable to get more than one IN1 segment.=0D=0A=0D=0A=0D=0AThanks=0D=0A=0D=
=0ATerry Waldron=0D=0ARMS Systems Analyst=0D=0AInformation Management=0D=0A=
Kingston General Hospital=0D=0A613 - 549 - 6666  ext. 3828=0D=0A=0D=0A=0D=0A=

[HAPI-devel] Terser Issue

[Waldron, T. <wal...@KG...>]

Hi,=0D=0A=0D=0AI'm trying to work with the 0.5 beta using the terser. With =
the 4.3 version I could use the code:=0D=0A=0D=0AString in1_3 =3D terser.ge=
t("/ADT_A01_IN1IN2IN3ROL(0)/IN1-3");=0D=0A=0D=0Ato get the string value. Wh=
en I do this with 0.5 beta on the same message, changing the group spec to =
ADT_A01_INSURANCE and adding a '.' so the code looks like this:=0D=0A=0D=0A=
String in1_3 =3D terser.get("/.ADT_A01_INSURANCE(0)/IN1-3");=0D=0A=0D=0AI g=
et the following error:=0D=0A=0D=0A=0D=0Aca.uhn.hl7v2.HL7Exception: End of =
message reached while iterating without loop=0D=0A=09at ca.uhn.hl7v2.util.M=
essageNavigator.iterate(MessageNavigator.java:242)=0D=0A=09at ca.uhn.hl7v2.=
util.SegmentFinder.findStructure(SegmentFinder.java:83)=0D=0A=09at ca.uhn.h=
l7v2.util.SegmentFinder.findGroup(SegmentFinder.java:71)=0D=0A=09at ca.uhn.=
hl7v2.util.Terser.getSegment(Terser.java:224)=0D=0A=09at ca.uhn.hl7v2.util.=
Terser.get(Terser.java:194)=0D=0A=09at Test_Terser.main(Test_Terser.java:57=
)=0D=0A=0D=0AWhat am I missing here=3F=20=0D=0A=0D=0A=0D=0A=0D=0ATerry Wald=
ron=0D=0ARMS Systems Analyst=0D=0AInformation Management=0D=0AKingston Gene=
ral Hospital=0D=0A613 - 549 - 6666  ext. 3828=0D=0A=0D=0A=0D=0A

Re: [HAPI-devel] Hello and a javadocs question

[Andrew M. <and...@ni...>]

Quoting Nico Vannieuwenhuyze <ni...@us...>:

> You can generate these javadocs yourself by downloading the source code 
> (core & 2.4) and running the ant-target "doc"

Ah, thanks very much.  I hadn't thought of downloading the source code.  I'll
grab that and generate the javadocs from that.  Thanks very much for your help.

-- 
Andrew McCaffrey
and...@ni...
----
The words above do not necessarily reflect the opinions of my employers or any
organization I may be associated with.  In fact, by the time you read them, they
may not even reflect my own opinions anymore.

[HAPI-devel] Hello and a javadocs question

[Andrew M. <and...@ni...>]

Greetings all,

I've downloaded your tool and am very happy to have something that will parse
HL7 messages for me.

I have a quick question. I cannot find the javadoc documentation for:
ca.uhn.hl7v2.model.v24.message.*
ca.uhn.hl7v2.model.v24.segment.*

Are there any javadocs available other than the ones at
<http://hl7api.sourceforge.net/javadoc/index.html>?  

Thanks for your time.

-- 
Andrew McCaffrey
and...@ni...
----
The words above do not necessarily reflect the opinions of my employers or any
organization I may be associated with.  In fact, by the time you read them, they
may not even reflect my own opinions anymore.

Re: [HAPI-devel] HAPI encoding

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

Hi Bernhard,

Encoding (eg ISO-8859-1) only comes into the picture when you read/write=20
from/to a file or a socket.

There was in a bug in hapi pre 0.4.3 with regards to encoding in the MLLP=20
classes, so if you're receiving the data from SAP over a socket upgrading=20
to 0.4.3 should solve your problem.

If you're reading the data from a file, please make sure to set the right=20
encoding on your stream constructor !

If you can't figure out, please send me a sample message and the piece of=20
code you use to parse the message.

Best Regards

Nico

At 19/07/2005, B=F6hm Bernhard wrote:
>Hi all,
>
>I am using the HAPI (0.4.2) classes to transform patients that have been=20
>exported from SAP, for mass loads (~ 1.000.000 persons), to a standard=20
>HL7-A08 message.
>The problem I have now, is a simple one, but I did not find a solution! We=
=20
>have, in our SAP system, sometimes strange characters stored, for example=
=20
>a =91#=92 in an address field. Now, to be able to parse the HL7 message,=20
>generated by HAPI, in our subsystem, I would need to encode the message in=
=20
>ISO-8859-1 encoding format (for those special characters). In the=20
>PipeParser-class, which I use to encode, I found a method =93encode(Message=
,=20
>String)=94 which should use a special encoding to generate the message.=
 But,=20
>unfortunately ISO-8859-1 seems not to be supported, as I always get an=20
>EncodingNotSupportedError!
>So, my question would be, if there is a possibility to encode in=20
>ISO-8859-1 or maybe there is another method that I did not find yet?!
>
>Thanks a lot in advance for your help!
>
>Regards
>Bernhard B=F6hm
>

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

[Jim K. <ji...@ho...>]

Hmm... The CDC implementation guides specified cr/lf, but I see that HAPI 
uses cr only, and given that I'm sending a message produced by HAPI I guess 
I mispoke when I stated that the message contained cr/lf (i didn't sic my 
hex editor on the file before i wrote that ;-))

I have confirmation from the vendor that they were treating the field 
delimiter as a postfix instead of a prefix and that was the cause of the 
problem.  They are working out a fix.

Thanks for your help on this issue.



>From: Archie Cobbs <ar...@de...>
>To: Jim Krygowski <ji...@ho...>
>CC: ni...@sk..., hl7...@li...
>Subject: Re: [HAPI-devel] Segment Terminator Rules for PIPE format
>Date: Thu, 14 Jul 2005 14:08:27 -0500
>
>Jim Krygowski wrote:
>>Thanks for the quick reply.  I'm using 0.4.3 and I'm 100% certain that 
>>there are no cr/lf characters anywhere but at the end of each segment.
>
>Hmm..
>
>Segements are supposed to be terminated with CR, not CR+LF, right?
>You shouldn't be sending the LF's I think.
>
>-Archie
>
>__________________________________________________________________________
>Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

[Jim K. <ji...@ho...>]

Hi Nico-

Thanks for the tip.  Fortunately for us, we're not in production currently 
so we have time to make the change.  This is the vendor's first attempt at 
developing an HL7 interface so there have been a few other situations like 
this before.  I was actually able to build a test suite using HAPI to make 
sure their interface was handling messages properly.  With the exception of 
the pre HAPI 0.5 XML issues, I generally consider HAPI to be the final 
authority on the validity of an HL7 message.

>From: Nico Vannieuwenhuyze <ni...@sk...>
>To: "Jim Krygowski" <ji...@ho...>, 
>bp...@gm...,hl7...@li...
>Subject: Re: [HAPI-devel] Segment Terminator Rules for PIPE format
>Date: Thu, 14 Jul 2005 07:46:26 +0200
>
>Hi Jim,
>
>If you can't wait for the receiving system to modify their code you can 
>maybe try to fill the characterset field (MSH-18) with ASCII or 8859/1 ...
>
>Could be that they'll give a warning on this field then ... but you'll 
>never know ...
>
>Regards
>
>Nico
>
>At 13/07/2005, Jim Krygowski wrote:
>>Hi Bryan-
>>
>>Thanks for the link to the relevant HL7 spec chapter.  The error message 
>>is:
>>
>>Error: Unable to split MSH Segment Invalid according to the required 
>>format.
>>ERROR: At MessageFormat: MSHHL7 Msg: ERROR: At FieldFormat: MSH.12.VID.1 
>>Type: String Msg: End of record encountered while parsing field 
>>MSH.12.VID.1
>>Message rejected.
>>
>>Which leads me to believe that they're not expecting the segment 
>>terminator.
>>
>>I have the balloted version of the 2.5 specification you referenced, and 
>>in that specification, the line of code you cited is struck out.  Do you 
>>have a later version?  The hl7.org site is a pain to navigate so I'm not 
>>sure if I'm looking at the right documents.  However, the code block that 
>>the struck code comes from is in the same spirit as what you're getting 
>>at:
>>
>>foreach segment in ( segment_list )
>>{
>>         print segment.name; /* e.g., MSH */
>>         /* gather all data for fields */
>>         foreach field in ( fields_of( segment ) )
>>         {
>>                 print field separator; /* e.g., | */
>>                 /* gather occurrences (may be multiple only for fields 
>>that are allowed to repeat */
>>                 foreach occurrence in ( occurrences_of( field ) )
>>                 {
>>                         transmit_occurrence( occurrence );
>>                         if not last ( populated occurrence ) print 
>>repetition_separator; /* e.g., ~ */
>>                 }
>>
>>                 break if last ( populated field );
>>         }
>>
>>         print segment_terminator; /* always Ox0AD<cr>! */
>>}
>>
>>So I think I have my answer.  I'm going off to talk with the vendor now.
>>
>>BTW: Congratulations and good luck on your PhD program.  Where will you be 
>>studying and what specifically are you going to focus on?
>>
>>
>>Thanks!
>>
>>>From: Bryan Tripp <bp...@gm...>
>>>Reply-To: Bryan Tripp <bp...@gm...>
>>>To: Jim Krygowski <ji...@ho...>
>>>CC: hl7...@li...
>>>Subject: Re: [HAPI-devel] Segment Terminator Rules for PIPE format
>>>Date: Wed, 13 Jul 2005 13:51:08 -0400
>>>
>>>Hi Jim,
>>>
>>>Does the interface engine give you a specific error message?
>>>
>>>There shouldn't be a trailing delimiter (see section 2.6.1 ... the
>>>wording in v2.5 is "if not last ( field ) print field_separator")
>>>
>>>Bryan
>>>
>>>On 7/13/05, Jim Krygowski <ji...@ho...> wrote:
>>> > I just started working with an HL7 interface that requires 
>>>pipe-delimited
>>> > style messages.  I'm using HAPI to generate the messages being sent 
>>>and for
>>> > some reason, the receiving gateway doesn't like what it's getting.
>>> >
>>> > HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 
>>>with
>>> > a cr/lf immediately following.  It looks perfectly valid, but the 
>>>interface
>>> > chokes on it.  I have to add the MSH.13 pipe delimiter after the 
>>>MSH.12
>>> > content in order for the message to be accepted.  This is the same for 
>>>any
>>> > message that doesn't have a value in the last possible field of a 
>>>segment.
>>> >
>>> > This is what HAPI produces:
>>> > MSH|^~\&|   |State Laboratory
>>> > 
>>>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1<hex
>>> > 0D0A>
>>> >
>>> > This is what the interface likes:
>>> > MSH|^~\&|   |State Laboratory
>>> > 
>>>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1|<hex
>>> > 0D0A>
>>> >
>>> > I've been delving into the HL7 specification docs on HL7.org but 
>>>they're not
>>> > terribly helpful.  I've got some pull with the interface vendor so if
>>> > they've done it wrong, we can have them change it.
>>> >
>>> > So, does anyone know which way is the right way?? Is HAPI failing to 
>>>put a
>>> > trailing delimiter in some cases?
>>> >
>>> > thanks in advance.
>>> >
>>> > Jim
>>> >
>>> >
>>> >
>>> >
>>> > -------------------------------------------------------
>>> > This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
>>>happening
>>> > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in 
>>>dual
>>> > core and dual graphics technology at this free one hour event hosted 
>>>by HP,
>>> > AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>>> > _______________________________________________
>>> > Hl7api-devel mailing list
>>> > Hl7...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>> >
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
>>happening
>>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>>core and dual graphics technology at this free one hour event hosted by 
>>HP,
>>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>>_______________________________________________
>>Hl7api-devel mailing list
>>Hl7...@li...
>>https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>

[HAPI-devel] HAPI encoding

[<ber...@vi...>]

Hi all,

=20

I am using the HAPI (0.4.2) classes to transform patients that have been =
exported from SAP, for mass loads (~ 1.000.000 persons), to a standard =
HL7-A08 message.

The problem I have now, is a simple one, but I did not find a solution! =
We have, in our SAP system, sometimes strange characters stored, for =
example a '#' in an address field. Now, to be able to parse the HL7 =
message, generated by HAPI, in our subsystem, I would need to encode the =
message in ISO-8859-1 encoding format (for those special characters). In =
the PipeParser-class, which I use to encode, I found a method =
"encode(Message, String)" which should use a special encoding to =
generate the message. But, unfortunately ISO-8859-1 seems not to be =
supported, as I always get an EncodingNotSupportedError!

So, my question would be, if there is a possibility to encode in =
ISO-8859-1 or maybe there is another method that I did not find yet?!

=20

Thanks a lot in advance for your help!

=20

Regards

Bernhard B=F6hm

=20

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

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

Jim Krygowski wrote:
> Thanks for the quick reply.  I'm using 0.4.3 and I'm 100% certain that 
> there are no cr/lf characters anywhere but at the end of each segment.  

Hmm..

Segements are supposed to be terminated with CR, not CR+LF, right?
You shouldn't be sending the LF's I think.

-Archie

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

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

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

Hi Jim,

If you can't wait for the receiving system to modify their code you can 
maybe try to fill the characterset field (MSH-18) with ASCII or 8859/1 ...

Could be that they'll give a warning on this field then ... but you'll 
never know ...

Regards

Nico

At 13/07/2005, Jim Krygowski wrote:
>Hi Bryan-
>
>Thanks for the link to the relevant HL7 spec chapter.  The error message is:
>
>Error: Unable to split MSH Segment Invalid according to the required format.
>ERROR: At MessageFormat: MSHHL7 Msg: ERROR: At FieldFormat: MSH.12.VID.1 
>Type: String Msg: End of record encountered while parsing field MSH.12.VID.1
>Message rejected.
>
>Which leads me to believe that they're not expecting the segment terminator.
>
>I have the balloted version of the 2.5 specification you referenced, and 
>in that specification, the line of code you cited is struck out.  Do you 
>have a later version?  The hl7.org site is a pain to navigate so I'm not 
>sure if I'm looking at the right documents.  However, the code block that 
>the struck code comes from is in the same spirit as what you're getting at:
>
>foreach segment in ( segment_list )
>{
>         print segment.name; /* e.g., MSH */
>         /* gather all data for fields */
>         foreach field in ( fields_of( segment ) )
>         {
>                 print field separator; /* e.g., | */
>                 /* gather occurrences (may be multiple only for fields 
> that are allowed to repeat */
>                 foreach occurrence in ( occurrences_of( field ) )
>                 {
>                         transmit_occurrence( occurrence );
>                         if not last ( populated occurrence ) print 
> repetition_separator; /* e.g., ~ */
>                 }
>
>                 break if last ( populated field );
>         }
>
>         print segment_terminator; /* always Ox0AD<cr>! */
>}
>
>So I think I have my answer.  I'm going off to talk with the vendor now.
>
>BTW: Congratulations and good luck on your PhD program.  Where will you be 
>studying and what specifically are you going to focus on?
>
>
>Thanks!
>
>>From: Bryan Tripp <bp...@gm...>
>>Reply-To: Bryan Tripp <bp...@gm...>
>>To: Jim Krygowski <ji...@ho...>
>>CC: hl7...@li...
>>Subject: Re: [HAPI-devel] Segment Terminator Rules for PIPE format
>>Date: Wed, 13 Jul 2005 13:51:08 -0400
>>
>>Hi Jim,
>>
>>Does the interface engine give you a specific error message?
>>
>>There shouldn't be a trailing delimiter (see section 2.6.1 ... the
>>wording in v2.5 is "if not last ( field ) print field_separator")
>>
>>Bryan
>>
>>On 7/13/05, Jim Krygowski <ji...@ho...> wrote:
>> > I just started working with an HL7 interface that requires pipe-delimited
>> > style messages.  I'm using HAPI to generate the messages being sent 
>> and for
>> > some reason, the receiving gateway doesn't like what it's getting.
>> >
>> > HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 
>> with
>> > a cr/lf immediately following.  It looks perfectly valid, but the 
>> interface
>> > chokes on it.  I have to add the MSH.13 pipe delimiter after the MSH.12
>> > content in order for the message to be accepted.  This is the same for any
>> > message that doesn't have a value in the last possible field of a segment.
>> >
>> > This is what HAPI produces:
>> > MSH|^~\&|   |State Laboratory
>> > 
>> Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1<hex
>> > 0D0A>
>> >
>> > This is what the interface likes:
>> > MSH|^~\&|   |State Laboratory
>> > 
>> Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1|<hex
>> > 0D0A>
>> >
>> > I've been delving into the HL7 specification docs on HL7.org but 
>> they're not
>> > terribly helpful.  I've got some pull with the interface vendor so if
>> > they've done it wrong, we can have them change it.
>> >
>> > So, does anyone know which way is the right way?? Is HAPI failing to put a
>> > trailing delimiter in some cases?
>> >
>> > thanks in advance.
>> >
>> > Jim
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
>> happening
>> > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>> > core and dual graphics technology at this free one hour event hosted 
>> by HP,
>> > AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>> > _______________________________________________
>> > Hl7api-devel mailing list
>> > Hl7...@li...
>> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>> >
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>core and dual graphics technology at this free one hour event hosted by HP,
>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>_______________________________________________
>Hl7api-devel mailing list
>Hl7...@li...
>https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

[Jim K. <ji...@ho...>]

Hi Bryan-

Thanks for the link to the relevant HL7 spec chapter.  The error message is:

Error: Unable to split MSH Segment Invalid according to the required format.
ERROR: At MessageFormat: MSHHL7 Msg: ERROR: At FieldFormat: MSH.12.VID.1 
Type: String Msg: End of record encountered while parsing field MSH.12.VID.1
Message rejected.

Which leads me to believe that they're not expecting the segment terminator.

I have the balloted version of the 2.5 specification you referenced, and in 
that specification, the line of code you cited is struck out.  Do you have a 
later version?  The hl7.org site is a pain to navigate so I'm not sure if 
I'm looking at the right documents.  However, the code block that the struck 
code comes from is in the same spirit as what you're getting at:

foreach segment in ( segment_list )
{
	print segment.name; /* e.g., MSH */
	/* gather all data for fields */
	foreach field in ( fields_of( segment ) )
	{
		print field separator; /* e.g., | */
		/* gather occurrences (may be multiple only for fields that are allowed to 
repeat */
		foreach occurrence in ( occurrences_of( field ) )
		{
			transmit_occurrence( occurrence );
			if not last ( populated occurrence ) print repetition_separator; /* e.g., 
~ */
		}

		break if last ( populated field );
	}

	print segment_terminator; /* always Ox0AD<cr>! */
}

So I think I have my answer.  I'm going off to talk with the vendor now.

BTW: Congratulations and good luck on your PhD program.  Where will you be 
studying and what specifically are you going to focus on?


Thanks!

>From: Bryan Tripp <bp...@gm...>
>Reply-To: Bryan Tripp <bp...@gm...>
>To: Jim Krygowski <ji...@ho...>
>CC: hl7...@li...
>Subject: Re: [HAPI-devel] Segment Terminator Rules for PIPE format
>Date: Wed, 13 Jul 2005 13:51:08 -0400
>
>Hi Jim,
>
>Does the interface engine give you a specific error message?
>
>There shouldn't be a trailing delimiter (see section 2.6.1 ... the
>wording in v2.5 is "if not last ( field ) print field_separator")
>
>Bryan
>
>On 7/13/05, Jim Krygowski <ji...@ho...> wrote:
> > I just started working with an HL7 interface that requires 
>pipe-delimited
> > style messages.  I'm using HAPI to generate the messages being sent and 
>for
> > some reason, the receiving gateway doesn't like what it's getting.
> >
> > HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 
>with
> > a cr/lf immediately following.  It looks perfectly valid, but the 
>interface
> > chokes on it.  I have to add the MSH.13 pipe delimiter after the MSH.12
> > content in order for the message to be accepted.  This is the same for 
>any
> > message that doesn't have a value in the last possible field of a 
>segment.
> >
> > This is what HAPI produces:
> > MSH|^~\&|   |State Laboratory
> > 
>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1<hex
> > 0D0A>
> >
> > This is what the interface likes:
> > MSH|^~\&|   |State Laboratory
> > 
>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1|<hex
> > 0D0A>
> >
> > I've been delving into the HL7 specification docs on HL7.org but they're 
>not
> > terribly helpful.  I've got some pull with the interface vendor so if
> > they've done it wrong, we can have them change it.
> >
> > So, does anyone know which way is the right way?? Is HAPI failing to put 
>a
> > trailing delimiter in some cases?
> >
> > thanks in advance.
> >
> > Jim
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
>happening
> > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> > core and dual graphics technology at this free one hour event hosted by 
>HP,
> > AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> > _______________________________________________
> > Hl7api-devel mailing list
> > Hl7...@li...
> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
> >

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

[Bryan T. <bp...@gm...>]

Hi Jim,=20

Does the interface engine give you a specific error message?=20

There shouldn't be a trailing delimiter (see section 2.6.1 ... the
wording in v2.5 is "if not last ( field ) print field_separator")

Bryan=20

On 7/13/05, Jim Krygowski <ji...@ho...> wrote:
> I just started working with an HL7 interface that requires pipe-delimited
> style messages.  I'm using HAPI to generate the messages being sent and f=
or
> some reason, the receiving gateway doesn't like what it's getting.
>=20
> HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 wi=
th
> a cr/lf immediately following.  It looks perfectly valid, but the interfa=
ce
> chokes on it.  I have to add the MSH.13 pipe delimiter after the MSH.12
> content in order for the message to be accepted.  This is the same for an=
y
> message that doesn't have a value in the last possible field of a segment=
.
>=20
> This is what HAPI produces:
> MSH|^~\&|   |State Laboratory
> Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|20050713113=
52900000|P|2.3.1<hex
> 0D0A>
>=20
> This is what the interface likes:
> MSH|^~\&|   |State Laboratory
> Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|20050713113=
52900000|P|2.3.1|<hex
> 0D0A>
>=20
> I've been delving into the HL7 specification docs on HL7.org but they're =
not
> terribly helpful.  I've got some pull with the interface vendor so if
> they've done it wrong, we can have them change it.
>=20
> So, does anyone know which way is the right way?? Is HAPI failing to put =
a
> trailing delimiter in some cases?
>=20
> thanks in advance.
>=20
> Jim
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

[Jim K. <ji...@ho...>]

Hi Nico-

Thanks for the quick reply.  I'm using 0.4.3 and I'm 100% certain that there 
are no cr/lf characters anywhere but at the end of each segment.  Hotmail 
garbled the sample message segments that i sent to the mailing list.  Each 
of those segments I sent are contained on one line when sent to the 
interface.

While digging through PipeParser I spotted this code at the end of the 
encode method:

return stripExtraDelimiters(result.toString(), 
encodingChars.getFieldSeparator());

It seems like this method is pretty indescriminate, it essentially wipes out 
all delimiters up to the last populated field.

I have a feeling that this is the source of my problem. However the real 
question is, what is the proper behavior according to the HL7 specification?

I'm working with a CDC ELR implementation guide that specifies how to use an 
ORU for ELR messaging.  In all the examples, if a segment terminates before 
exhausting all possible fields, the segment terminates with pipe+cr/lf. so:

MSH|MSH.1|.....|MSH.12|<cr/lf>

If the segment terminates with the last field filled then it terminates with 
just <cr/lf>:

MSH|MSH.1|....||MSH.20<cr/lf>

I noticed that the examples of HL7 vendors like Chameleon follow a similar 
approach.  Is this approach right?  I'm inclined to think it may be but I 
can't track down the HL7 specification that states it definitively.  If the 
approach is right, then the stripExtraDelimiters method is a problem.

Re: [HAPI-devel] Segment Terminator Rules for PIPE format

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

Hi Jim,

Could you please send me the peace of code you're using to construct the 
message ?

What version of hapi are you using ?

Are you sure that your string "State Laboratory Institute" doesn't contain 
a carriage return linefeed after the "Laboratory" ?

It's not allowed to send a carriage return linefeed (ASCII 13 + 10) in a 
HL7 message.

A carriage return (ASCII 13) is allowed/required but only as segment 
terminator (after each segment).

Best Regards

Nico

At 13/07/2005, Jim Krygowski wrote:
>I just started working with an HL7 interface that requires pipe-delimited 
>style messages.  I'm using HAPI to generate the messages being sent and 
>for some reason, the receiving gateway doesn't like what it's getting.
>
>HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 
>with a cr/lf immediately following.  It looks perfectly valid, but the 
>interface chokes on it.  I have to add the MSH.13 pipe delimiter after the 
>MSH.12 content in order for the message to be accepted.  This is the same 
>for any message that doesn't have a value in the last possible field of a 
>segment.
>
>This is what HAPI produces:
>MSH|^~\&|   |State Laboratory 
>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1<hex 
>0D0A>
>
>This is what the interface likes:
>MSH|^~\&|   |State Laboratory 
>Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1|<hex 
>0D0A>
>
>I've been delving into the HL7 specification docs on HL7.org but they're 
>not terribly helpful.  I've got some pull with the interface vendor so if 
>they've done it wrong, we can have them change it.
>
>So, does anyone know which way is the right way?? Is HAPI failing to put a 
>trailing delimiter in some cases?
>
>thanks in advance.
>
>Jim
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>core and dual graphics technology at this free one hour event hosted by HP,
>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>_______________________________________________
>Hl7api-devel mailing list
>Hl7...@li...
>https://lists.sourceforge.net/lists/listinfo/hl7api-devel

[HAPI-devel] Segment Terminator Rules for PIPE format

[Jim K. <ji...@ho...>]

I just started working with an HL7 interface that requires pipe-delimited 
style messages.  I'm using HAPI to generate the messages being sent and for 
some reason, the receiving gateway doesn't like what it's getting.

HAPI is generating a MSH segment with delimiters for MSH.1 thru MSH.12 with 
a cr/lf immediately following.  It looks perfectly valid, but the interface 
chokes on it.  I have to add the MSH.13 pipe delimiter after the MSH.12 
content in order for the message to be accepted.  This is the same for any 
message that doesn't have a value in the last possible field of a segment.

This is what HAPI produces:
MSH|^~\&|   |State Laboratory 
Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1<hex 
0D0A>

This is what the interface likes:
MSH|^~\&|   |State Laboratory 
Institute^22D0650270^CLIA|ELRMADPH|MA|20050713113529||ORU^R01|2005071311352900000|P|2.3.1|<hex 
0D0A>

I've been delving into the HL7 specification docs on HL7.org but they're not 
terribly helpful.  I've got some pull with the interface vendor so if 
they've done it wrong, we can have them change it.

So, does anyone know which way is the right way?? Is HAPI failing to put a 
trailing delimiter in some cases?

thanks in advance.

Jim

[HAPI-devel] stepping down

[Bryan T. <bp...@gm...>]

This is to announce that I am stepping down as Chief Developer of
HAPI, effective today. I'm leaving in order to focus full-time on my
PhD.

I'm very pleased to say that James Agnew will be taking over. James is
a colleague of mine at University Health Network. He started working
with HAPI about 2 1/2 years ago, when he led the team that developed
our conformance class generation code. He is a very capable
programmer, and also exceptionally level-headed and approachable.
You'll like him.

It has been a real pleasure meeting and working with all of you. Since
HAPI's inception in 2001, I have been getting emails from developers
around the world (at least 25 different countries!) and I have very
much enjoyed meeting so many different people and hearing about the
good work going on everywhere, and I'll miss it. Thank you to everyone
who helped out with code, bug reports, organizational details, and
encouragement. There have been dozens of you over the years. I'm
tempted to list a few who have been particularly supportive in various
ways, although I know I will miss somebody. Well, here goes anyway:
Leslie Mann, Nico Vannieuwenhuyze, Neal Acharya, Alexei Geuvara, Laura
Sato, Wes Rishel, Harriet Hu, Archie Cobbs, Joe Rosario, Eric Poiseau,
Jim Forbes, Matt Anderson, and Fr=E9d=E9ric Dubru.

Although I won't be leading the project any more, I will still be
available to help out as needed.

All the best!=20

Bryan

RE: [HAPI-devel] Working with different HL7 versions

[Rochana A. <ro...@lk...>]

Hi Bryan,

Thanks for your reply.

I tried to use an external attribute mapping scheme for each external
system to overcome this problem without having to change the code. My
idea was to map the attributes in my system to the external system
attributes since some ext systems don't comply to the HL7 specification
completely. The mapping looked something like this:

<external-value>PID 3,0</external-value>
<interpretation></interpretation>
<interpretation-type>equiv</interpretation-type>
<my-attribute>PID_fName</my-attribute>

e.g. the external value was expressed in the format: [Segment]
[Field],[Component],[Subcomponent].

Then I extracted the data from the level of Primitives, Varies, etc. And
then things got complicated when I had to check the place where the data
was placed in a Message and trying to figure out how to get them out
without being version specific. It seemed to vary from case to case.
Basically, I couldn't find a way to handle this on a generic level. And
it got even more complicated when I tried to handle grouped segments
like IN1,ZPA, etc.

Is there any documentation that specifies how HAPI handles different
types of segments in a generic way? Is it possible to overcome my
version problem with a mapping scheme?

Rochana.



-----Original Message-----
From: Bryan Tripp [mailto:bp...@gm...]=20
Sent: Thursday, July 07, 2005 8:04 PM
To: Rochana Attale
Cc: hl7...@li...
Subject: Re: [HAPI-devel] Working with different HL7 versions

Hi Rochana,=20

The class ca.uhn.hl7v2.util.Terser provides a version-independent way
to get and set field values.

It handles some changes between versions automatically, for example if
a primitive turns into a composite, then requests for the primitive
are interpreted as requests for the first component (which according
to HL7 rules is supposed to have the same meaning). If the segment
grouping changes between versions though, you have to handle the
different cases in your own code.

Bryan=20

On 7/7/05, Rochana Attale <ro...@lk...> wrote:
>=20
>=20
> Hi,
>=20
> =20
>=20
> I have to process HL7 files that come in different versions. How do I
handle
> this as HAPI defines data types per version (e.g.
> ca.uhn.hl7v2.model.v23.datatype,
> ca.uhn.hl7v2.model.v231.datatype,
> ca.uhn.hl7v2.model.v24.datatype) ?
>=20
> =20
>=20
> Rochana.

Re: [HAPI-devel] Working with different HL7 versions

[Bryan T. <bp...@gm...>]

Hi Rochana,=20

The class ca.uhn.hl7v2.util.Terser provides a version-independent way
to get and set field values.

It handles some changes between versions automatically, for example if
a primitive turns into a composite, then requests for the primitive
are interpreted as requests for the first component (which according
to HL7 rules is supposed to have the same meaning). If the segment
grouping changes between versions though, you have to handle the
different cases in your own code.

Bryan=20

On 7/7/05, Rochana Attale <ro...@lk...> wrote:
>=20
>=20
> Hi,
>=20
> =20
>=20
> I have to process HL7 files that come in different versions. How do I han=
dle
> this as HAPI defines data types per version (e.g.
> ca.uhn.hl7v2.model.v23.datatype,
> ca.uhn.hl7v2.model.v231.datatype,
> ca.uhn.hl7v2.model.v24.datatype) ?
>=20
> =20
>=20
> Rochana.

[HAPI-devel] Working with different HL7 versions

[Rochana A. <ro...@lk...>]

Hi,

=20

I have to process HL7 files that come in different versions. How do I
handle this as HAPI defines data types per version (e.g.
ca.uhn.hl7v2.model.v23.datatype, ca.uhn.hl7v2.model.v231.datatype,
ca.uhn.hl7v2.model.v24.datatype) ?

=20

Rochana.