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