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

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

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

[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

[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

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

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