Repeated/Unexpected Segment & Splitting -- Loss of 2nd Error

Post author
Christopher Roedocker

We are testing against a HIPAA 5010 834 document using splitting over Loop 2000 where two splits exist. Each split has an instance of an errantly repeated segment (unexpected segment). We are observing that an error will be reported over the first split, however, no error will be reported over the second split. The generated 999 will only report the first error.

Demo Code:

        private void ParseFile_ModMethod_AckManValidate(string filePath)
        {
            var ediStream = File.OpenRead(filePath);

            var ackSettings = new AckSettings()
            {
                AckHandler = HandleAcknowledgementEvent(),
                MessageHandler = HandleMessageEvent(),
                AckVersion = AckVersion.Hipaa_999,
                GenerateForValidMessages = true,
                GroupDuplicates = true,
                TransactionSetDuplicates = true,
                IncludeLoopId = true
            };

            var ackMan = new AckMan(ackSettings);
            var ediReader = new X12Reader(ediStream, (isa, gs, st) => typeof(TS834Splitter).GetTypeInfo(), new X12ReaderSettings() { Split = true, ContinueOnError = true });

            while (ediReader.Read())
            {
                if (!(ediReader.Item is TS834Splitter item))
                {
                    ackMan.Publish(ediReader.Item);
                    continue;
                }

                ackMan.Publish(item);   // BREAKPOINT A1
            }

            ackMan.Dispose();
        }

        private EventHandler<MessageEventArgs<ISA, GS>> HandleMessageEvent() =>
            (s, a) =>
            {
                bool hasErrors = false; // BREAKPOINT B1

                if (a.ErrorContext.HasErrors)
                {
                    hasErrors = true;
                }
                else
                {
                    hasErrors = false;
                }
            };

        private EventHandler<AckEventArgs<ISA, GS>> HandleAcknowledgementEvent() =>
            (s, a) =>
            {
                if (!(a.Message is TS999 ts999))
                    return;

                var memoryStream = new MemoryStream();

                using (var writer = new X12Writer(memoryStream, new X12WriterSettings() { Encoding = Encoding.Default, Postfix = Environment.NewLine }))
                {
                    writer.Write(ts999);
                }

                string ackResults = null;

                memoryStream.Position = 0;
                using (var reader = new StreamReader(memoryStream))
                    ackResults = reader.ReadToEnd();    // BREAKPOINT C1
            };

 

Payload 1 -- First split has multiple 2000.REF*0F segments, second split has multiple 2100A.NM1*IL segments:

ISA*00*          *00*          *ZZ*453358287P     *ZZ*264595216      *240430*1238*^*00501*000386762*1*P*:~
GS*BE*930995828*936030398*20240430*1238*4647*X*005010X220A1~
ST*834*000000001*005010X220A1~
BGN*00*000000001*20240430*123833*CT***2~
REF*38*WA900000~
DTP*007*D8*20240430~
N1*P5*INSURER_2*FI*936030398~
N1*IN*INSURER_2*FI*264595216~
INS*Y*18*021*28*A***AC~
REF*0F*1111111111111111~
REF*0F*1111111111111111~
DTP*336*D8*19920724~
NM1*IL*1*LAST1*MIDDLE1*FIRST1***34*111223333~
PER*IP**HP*5551110000~
N3*123 ADDRESS1~
N4*SHAWNEE MISSION*KS*66276~
DMG*D8*19920724*M*D~
HD*021**DEN*7*EMP~
DTP*348*D8*20240430~
DTP*349*D8*20300614~
INS*Y*18*021*28*A***AC~
REF*0F*2222222222222222~
DTP*336*D8*19910710~
NM1*IL*1*LAST2*MIDDLE2*FIRST2***34*222334444~
NM1*IL*1*LAST2*MIDDLE2*FIRST2***34*222334444~
PER*IP**HP*5552220000~
N3*234 ADDRESS2~
N4*WARNER*NH*03278~
DMG*D8*20001007*F*D~
HD*021**DEN*7*EMP~
DTP*348*D8*20240430~
DTP*349*D8*20321222~
SE*31*000000001~
GE*2*4647~
IEA*1*000386762~

When X12Reader is reading the first split (BREAKPOINT A1), we see the desired error being captured in ErrorContext (Unexpected REF*0F Segment). However, when reading the second split, the ErrorContext still matches that of the first split, while we can observe that the SplitPosition property has updated.

Within the AckMan's MessageHandler event (BREAKPOINT B1), we can see that only one error is captured in the event arguments.

Following the generation of the 999 tx set within AckMan's acknowledgement event handler (after BREAKPOINT C1), the 999 shows only the unexpected REF*0F but does not report the unexpected NM1*IL.

ST*999*0001*005010X231A1~
AK1*BE*4647*005010X220A1~
AK2*834*000000001~
IK3*REF*9**2~
IK5*R*4*5~
AK9*R*2*1*0~
SE*7*0001~

Payload 2 -- First split has multiple 2100A.NM1*IL 2 segments, second split has multiple 000.REF*0F  segments:

ISA*00*          *00*          *ZZ*453358287P     *ZZ*264595216      *240430*1238*^*00501*000386762*1*P*:~
GS*BE*930995828*936030398*20240430*1238*4647*X*005010X220A1~
ST*834*000000001*005010X220A1~
BGN*00*000000001*20240430*123833*CT***2~
REF*38*WA900000~
DTP*007*D8*20240430~
N1*P5*INSURER_2*FI*936030398~
N1*IN*INSURER_2*FI*264595216~
INS*Y*18*021*28*A***AC~
REF*0F*1111111111111111~
DTP*336*D8*19920724~
NM1*IL*1*LAST1*MIDDLE1*FIRST1***34*111223333~
NM1*IL*1*LAST1*MIDDLE1*FIRST1***34*111223333~
PER*IP**HP*5551110000~
N3*123 ADDRESS1~
N4*SHAWNEE MISSION*KS*66276~
DMG*D8*19920724*M*D~
HD*021**DEN*7*EMP~
DTP*348*D8*20240430~
DTP*349*D8*20300614~
INS*Y*18*021*28*A***AC~
REF*0F*2222222222222222~
REF*0F*2222222222222222~
DTP*336*D8*19910710~
NM1*IL*1*LAST2*MIDDLE2*FIRST2***34*222334444~
PER*IP**HP*5552220000~
N3*234 ADDRESS2~
N4*WARNER*NH*03278~
DMG*D8*20001007*F*D~
HD*021**DEN*7*EMP~
DTP*348*D8*20240430~
DTP*349*D8*20321222~
SE*31*000000001~
GE*2*4647~
IEA*1*000386762~

For this payload the behavior matches that of the first payload, except with the error reporting over the unexpected 2100A.NM1 segment. When the 999 text is generated (after BREAKPOINT C1), we can see that only the unexpected NM1*IL is reported, without indication of unexpected REF*0F.

ST*999*0001*005010X231A1~
AK1*BE*4647*005010X220A1~
AK2*834*000000001~
IK3*NM1*11**2~
IK5*R*4*5~
AK9*R*2*1*0~
SE*7*0001~

Comments

2 comments

  • Comment author
    Christopher Roedocker

    It was observed after posting that both payloads have an incorrect GE01 value of 2. The results remain the same with a payload where GE01 value is 1.

    0
  • Comment author
    Admin

    Hello Christopher,

    Yes, this is correct - only the first parsing error is reported, and all subsequent parsing errors are omitted. This is because if a parsing error occurs, all segments after the errors are potentially incorrect and must be disregarded. The fact that the parser continues to recover whatever it can be recovered - the data is inconsistent, and it can't be determined whether a new parsing error is due to the initial parsing error or on its own.

    In other words, if there is a parsing error, the message must not be validated and is not recommended to be used.

    In your example, I can see the value of having both parsing errors reported in both parts, although the final acknowledgment covers the whole message, and only the first parsing error must be reported for the reasons above. In the next release, we will add the option to configure the reader to collect all parsing errors (if ContinueOnError is selected).

     

    1

Please sign in to leave a comment.