#24 Parser/FilterIterator populating unreferenced MSA segment

[Anonymous]

I'm very new to NHapi, but I'm tracing through and seeing what I can only imagine is a bug.

When PipeParser parse() an ACK for its AcknowledgementCode, the value is always coming back null, even though the text reads "AA".

As I trace through the parser routine, PipeParser.cs line 314 retrieves dirIter.Current for population by Parse() from the segment plaintext. When the segment loop has reached the MSA segment, dirIter.Current returns a new MSA object - not the same object reference as the one referenced by the local IMessage m.

Tracing into Parse from line 314 ... by the end of this function, the MSA's AcknowledgementCode field IS POPULATED CORRECTLY with "AA", but (restating the above) the segment object that is being populated is not the one referenced by the caller's local IMessage m and so the parsed segment is discarded and the default/empty segment originally created by InstantiateMessage() is returned.

I'm too new to NHapi to understand how to fix this, understand the extent of the impact of this behavior (beyond MSA-1). I'm using a codeset from December 21, 2011

[ChadC]

Can you please post your message (or a sample with PHI removed).

[Anonymous]

The ACK message being parsed:

MSH|^~\&|^Vendor Application||||20120112114958||ACK|NxMsg455|^D|2.5
NTE
MSA|AA|NxMsg455

[Anonymous]

Can this be confirmed as a bug?

[ChadC]

I think the message you have is malformed. When I remove the NTE segment, it parses correctly. An ACK shouldn't have an NTE segment... the parser is pretty particular that the correct segments show up where they should otherwise following segments get screwed up and don't get set correctly.

This code worked for me:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NHapi.Base.Parser;
using NHapi.Model.V25.Message;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string test = @"MSH|^~\&|^Vendor Application||||20120112114958||ACK|NxMsg455|^D|2.5
MSA|AA|NxMsg455";
PipeParser p = new PipeParser();
ACK ack =(ACK)p.Parse(test);
Console.WriteLine(ack.MSA.AcknowledgmentCode.Value);
Console.ReadLine();
}
}
}

[Nobody/Anonymous]

Thank you for this analysis. I'll talk to our remote contact about their response.

Is it intended behavior that this would then fail silently? If the minimum required segments are present, shouldn't any additional segments just be listed under non-standard segments?

[ChadC]

It has been a while since I've looked into the parser code, but It has issues when it starts running into segments that it doesn't expect. Since that had an NTE segment, and it expected a MSA segment, the parser kind of freaks out and doesn't know where to put that NTE data, so it pretty much can't (or stops) parsing the rest of the message.

The libraries work great as long as your messages follow the HL7 2.X message specifications for the segments order/requiredness. If you have wierd message specifications, then you would have to basically create your own HL7 2.X message formats (which I have done here for UCH, you'd see those in the source repository under 25UCH). The easiest way that I did this was by taking the HL7 database and modifying the structure to be the way we send messages. Then creating the specific version for us. It is work, but way worth it because you get all everything set correctly via the object model.

[Nobody/Anonymous]

Well, part of the issue is that we need to validate the messages! If they don't conform to the spec, then an exception should be thrown, no? Otherwise, we don't know that information has been lost, in the general case.