CLM is never in a 2300 loop but should always be.

[mcpierce]

According to the 837 technical references such as this [1] the CLM segment should be in the 2300 loop. However, using the X12 parser library I'm consistently seeing it being in the 2400 loop when present.

My code is using the ANSI837_5010_X222 file type.

[1] https://ushik.ahrq.gov/ViewItemDetails?&system=apcd&itemKey=196746000

Below is a sample 837 that I've hopefully correctly scrubbed without damaging the content:

ISA*00*          *00*          *ZZ*133052274      *ZZ*044300001      *210615*0515*^*00501*000001001*0*P*:~GS*HC*133052274*044300001*20210615*051514*1001*X*005010X222A1~ST*837*000000001*005010X222A1~BHT*0019*00*000000D14*20210614*051514*CH~NM1*41*2*VENDOR*****46*133052274~PER*IC*VENDOR CUSTOMER SOLUTIONS*TE*8008456592~NM1*40*2*CLIENT SERVICES*****46*044300001~HL*1**20*1~NM1*85*2*CLIENT IMAGING*****XX*1053386219~N3*123 MAIN STREET~N4*ANYTOWN*NY*123451234~REF*EI*010752765~PER*IC*OPI*TE*4045001658~NM1*87*2~N3*PO BOX 123~N4*ANYTOWN*NY*123451234~HL*2*1*22*0~SBR*P*18**CLIENT SERVICES*****CI~NM1*IL*1*JONES*JANET****MI*D0140~N3*456 UPTOWN ROAD~N4*ANYTOWN*NY*12345~DMG*D8*19590630*F~NM1*PR*2*CLIENT SERVICES*****PI*04430~CLM*OPI56804*2011***11:B:1*Y*A*Y*Y*P~REF*X4*11D2166278~REF*D9*061421748936058~REF*G1*NPR~HI*ABK:M5136~NM1*DN*1*JORDAN*JUDY*W***XX*2342342345~NM1*82*1*NANJANI*RAJESH*D***XX*1231231234~PRV*PE*PXC*2085R0202X~NM1*77*2*CLIENT IMAGING*****XX*1053386219~N3*123 MAIN STREET~N4*ANYTOWN*NY*123451234~LX*1~SV1*HC:72148*2011*UN*1***1~DTP*472*RD8*20210610-20210610~REF*6R*7436591237~SE*37*000000001~GE*3*1001~IEA*1*000001001~

When parsed by the X12 library the patient MRN (OPI56804) is reported as being in the 2400 loop when it should be in the 2300 loop.

[angelaszek]

I wasn't able to reproduce this. Here is the code from the unit test I wrote. I put the data you provided in the test.txt file.

` URL url = this.getClass().getResource("/837_5010/test.txt");
X12Reader reader = new X12Reader(FileType.ANSI837_5010_X222, new File(url.getFile()));

    Assert.assertEquals(1, reader.getLoops().size());
    Assert.assertEquals(1, reader.getLoops().get(0).findLoop("2300").size());
    Assert.assertNotNull(reader.getLoops().get(0).getLoop("2300").getSegment("CLM"));
    Assert.assertEquals(1, reader.getLoops().get(0).findLoop("2400").size());
    Assert.assertNull(reader.getLoops().get(0).getLoop("2400").getSegment("CLM"));
    Assert.assertEquals("OPI56804", reader.getLoops().get(0).getElement("2300", "CLM", "CLM01"));`

[mcpierce]

In my case the code isn't explicitly looking for the 2300 loop, Instead, once the 837 is loaded, it starts at the top and goes through each loop, segment, element and value and they are loaded into a Java data model. Does the 2300 loop not show up when using methods like getInnerLoops() of Loop?

[angelaszek]

Here are some examples that might help:

This gets the top of the overall structure
Loop loop = reader.getLoops().get(0);

Now lets get the first loop 2000B in the structure
Loop loop2000B = loop.findLoop("2000B").get(0)

If you do loop2000B.getLoops() it will return Loop 2300 since it is a direct child loop of Loop 2000B. getLoops() won't return Loop 2400 directly since it is one level down and a child loop of Loop 2300. You will need to call getLoops() on the 2300 loop object to get to the Loop object for 2400.

To get loop 2400 directly from loop 2000B (or any other loop higher than loop 2400) you can do something like this:
Loop loop2400 = loop2000B.findLoop("2400").get(0)
This is because findLoop searches through the child loops to find loop 2400.

Hopefully this helps answer your question.

[mcpierce]

Closing this as not-a-bug.

It turns out in our document builder code, we were not restoring the parent loop when descending into child loops. The 2300 loops was the symptom that made this error apparent.

Thanks for the great library!