Hi Johnny,
You are probably running up against one of the more unusual features of the
parser. If it detects a segment it doesn't expect, it will move to the end
of the current group, and add a non standard segment there.
Unfortunately, this often has the by-product of causing it to skip past the
natural location of segments which come later in the message, so they end up
being added as nonstandard segments in a child group.
The end result is that the message will re-encode (seemingly) correctly, but
if you actually examine the structures in the message, pretty much
everything in the message after the unexpected segment is in a wacky place.
This is something I have a fix for in the next version of HAPI (it's part of
a huge cleanup of how the PipeParser works I'm doing in order to improve
performance and allow the parser to deal with unexpected situations more
gracefully), but I don't expect to be able to release this for a while yet.
Incidentally, you are also getting hit by another bug which the cleanup
addresses, which is that messages are currently given a single empty
repetition of all optional repeating segments, even if none were in the
original message being parsed. ormMsg.getNTE(i) returns null, but that's not
actually where the content in the NTE segment in your message ended up.
The easiest way to figure out where the contents went (other than waiting
for the next version of HAPI :) ) is to save the contents of your message in
a text file, and use the treepanel to parse and display the message tree:
ca.uhn.hl7v2.view.TreePanel(new String[] { "message_file.hl7" } );
Browse around and you should be able to find the contents you are looking
for and which repetitions of which groups they are in.
Cheers,
James
On Tue, Aug 4, 2009 at 9:26 AM, Johnny2R <[email protected]> wrote:
>
> I've run into a strange problem with an NTE segment in an HL7 message which
> I
> think is malformed (but which I still have to be able to deal with). The
> messages I'm receiving have an NTE segment after the PD1 segment, whereas I
> think it should be after the MSH segment. HAPI chokes on it somewhat, in
> that it knows it's there but doesn't deal with it right. In the code below,
> nteRepCount is correctly set to 1, and ormMsg.getNTE(i) returns a non-null
> NTE. But all the fields of the NTE are null. If I reformat the message so
> that the NTE segment is where it should be, this gives me the data I'm
> expecting.
>
> int nteRepCount = ormMsg.getNTEReps();
> for (int i = 0; i <= nteRepCount; i++) {
> NTE nte = ormMsg.getNTE(i);
> String value = nte.getComment(0).toString();
> }
>
> Now, I'm wondering how I can actually grab the real NTE segment even if it
> is mislocated. Unfortunately I'm working with a big established hospital
> system which isn't about to be changed merely because it's sending
> malformed
> messages - it's something my code has to cope with. I was hoping I could
> use
> the lower-level Terser to get the values but that still gives me a non-null
> but empty NTE.
>
> This is using HAPI 0.6 (I upgraded from 0.5.1).
> --
> View this message in context:
> http://www.nabble.com/Problem-with-misplaced-NTE-segment-tp24808667p24808667.html
> Sent from the hl7api-devel mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Hl7api-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Hl7api-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
