This project has moved. For the latest updates, please go here.

Error with 4010 Professional

Jan 16, 2014 at 11:19 PM
Dear dstrubhar,

I am using the X12Parser release 2.3.4.

I get the following error when processing a 4010 professional EDI X12 837 claim:
Segment 'DMGD819521106F' in position 28 within transaction '0001' cannot be identified within the supplied specification for transaction set 837

We did some investigation and found that the issue appears to be with the 'QD' qualifier in the NM segment

The claim is parsed by the X12 parser successfully if we delete the following text in the Claim:

lastnamefirstname~N3street address~N4BROOKLYN PARKFL12345~DMGD819521106F

Can you please advise what are our options?

Your kind help will be greatly appreciated.

Jan 22, 2014 at 11:00 PM
Can someone on the X12Parser team please help with this issue? How do we workaround these issues a 4010 837 claim?

Thank you, in advance, for all your help.

Jan 23, 2014 at 12:14 AM
I need a little more of the your failing transaction to troubleshoot.
QD stands for Responsible Party which is usually a child of the Subscriber Loop in the 4010 version. Is this an institutional claim?

This may be happening if you are encountering the NM1*QD segment in a patient loop instead of a subscriber loop which won't expect that loop.

To fix it just for you, you can over write the build in 837-4010 specification by implementing your own SpecificationFinder.

The DMG segment only appears in the subscriber name or the patient name loops.

If I had to guess with what you have given me, I would say it is probably a bug where they meant to use QC which is a patient loop instead of QD.

If this is a bug from the sender, it is better that they fix it, if you change your specification so that this won't throw an exception, you may end up taking in invalid data.
Jan 23, 2014 at 4:13 PM
Dear dstrubhar,
Thank you so much for your response and help in this matter. Indeed, this is a 4010 Institutional Claim. Here's a little more information of the failing transaction. The failing segment is in BOLD text:

ISA00 01SOMENAME ZZPROD ZZCLAIMSCH 1301100141U004010000090891P>~GSHCP392096ABCCLAIMS201301100141000000X004010X098A1~ST8370001~BHT001900000000000201301100141CH~REF87004010X098A1~NM1412ABCDEFG HEALTH CARE46123456392111~PERICFNAME LNAMETE1111111111EX7026FX111111111~NM1402SOMENAME46CLAIMSCH~HL1201~NM1852ABCDEFG HEALTH CAREXX1982737185~N31234 STREET~N4CITYST123451111~REFG2123456789~REF0B330905~REFEI123456789~PERICABCDEFG HEALTH CARETE7635205473~HL21220~SBRP18AM~NM1IL1LNAMEFNAMEMI123456789~N31234 STREET AVE N~N4CITY PARKST12345~DMGD819000114M~NM1PR2MY INS CO STATEPI5861~N3X.X. XXX 123456ABC DEF PROCESSING CENTER~N4CITYST12345~REF2UWS081__~NM1QD1LNAMEFNAME~N31234 ST N~N4CITYST55443~DMGD819000114M__~NM1842MY HOTELEI000-00-0000~CLM12345678948223>>1YAYYBAA>>>MN~DTP439D820130101~DTP435D820130101~DTP096D820130101~REFEA2639672~HIBK>920BF>72885BF>

If you still think it is probably a bug from the sender, we will contact them to fix it.

Here's another issue we are seeing:

error = Segment 'NM1
EI123-45-6789' in position 26 within transaction '0001' cannot be identified within the supplied specification for transaction set 837.

Here's more information about this failed claim:

01CYCTRANS ZZPROD ZZCLAIMSCH 1301110141U004010000090921P>~GSHCP392096ABCCLAIMS201301110141159903X004010X098A1~ST8370001~BHT001900012345678201301110141CH~REF87004010X098A1~NM1412ABC HEALTH4601234567891234~PERICFNAME LNAMETE0123456789EX7026FX0123456789~NM1402XXXX46CLAIMSCH~HL1201~NM1852ABC HEALTH***XX111111111~N31234 STREET NO~N4CITYST012345679~REFG2123456789~REF0B330905~REFEI123456789~PERICABC DEF HEALTHTE1234567890~HL21220~SBRP18AM~NM1IL1LNAMEFNAMERMI1234567800000000~N31234 STREET AVE N~N4MY CENTERMN55429~DMGD819000921M~NM1PR2ABC DEFPI5861~N3ONE TWO THREE~N4CITYST12345~REF2UWCG01~__NM1842JACK AND JILLEI123-45-6789__~CLM12345678974623>>1YAYYBAA>>>

Can you please comment if the 2nd issue has anything in common? Is it because of an unexpected qualifier in a specific loop?

Our entire team remains grateful to you for all your prompt help in the past couple years. This open source project deserves all the KUDOS out there!

Kind Regards,
Jan 23, 2014 at 4:46 PM
Here is a breakdown of your transaction:
ISA00 01SOMENAME ZZPROD ZZCLAIMSCH 1301100141U004010000090891P>~
      NM1412ABCDEFG HEALTH CARE46123456392111~
        PERICFNAME LNAMETE1111111111EX7026FX111111111~
      HL1201~                            HL Loop 1, No Parent, Level Code = Information Source (Billing Provider)
        NM1852ABCDEFG HEALTH CAREXX1982737185~
          N31234 STREET~
        HL21220~                        HL Loop 2, Parent Loop 1, Level Code = Subscriber, Loop ID 2000B
          NM1IL1LNAMEFNAMEMI123456789~                      LOOP ID - 2010BA Subscriber Name
            N31234 STREET AVE N~
            N4CITY PARKST12345~
          NM1PR2MY INS CO STATEPI5861~                      LOOP ID - 2010BC Payer Name
          NM1QD1LNAMEFNAME~                                 LOOP ID - 2010BD Responsible Party Name
            N31234 ST N~
            DMGD819000114M__~                              ** THIS IS THE PROBLEM, Loop 2010BD does not allow DMG in the 4010 Implementation guide, however the generic x12 standard does allow DMG int he 2010 loop.
          NM1842MY HOTELEI000-00-0000~                     ** ODD, 84 is the code for Subscriber's Employer, this might me some custom implementation not in the standard Implementation Guide
          CLM12345678948223>>1YAYYBAA>>>MN~                LOOP ID - 2300 CLAIM Information
The problem is that your sender is sending you something that is X12 compliant, but is not in the 4010 Institutional Implementation Guide issued by WPC. Since the message isn't invalid I went ahead and updated the embedded 837 spec for 4010 so that it can handle your message. I also had to add a loop for your NM184 segment which is also not in the Implementation Guide. The changes are in changeset 34117.
Jan 23, 2014 at 9:05 PM
Dear dstrubhar,
I can't thank you enough for all your prompt help with these issues! I can't tell you how much time & effort you have saved us, not to mention this will tremendously help meet our project deadline.

In regards to implementing changeset 34117 at our end... we are currently using Release 2.3.4 of the X12Parser DLLs (including unbundlex12 functionality). We first call the parser.UnbundleByLoop( ) function to unbundle the claim, followed by running each unbundled X12 through an XSLT to generate an XML representation of the claim. How do I go about implementing the change you helped us here?

Thank you again for everything! We really appreciate it.
Kind Regards,
Jan 23, 2014 at 9:23 PM
I will be doing a new release by the end of the month.
Until then you can grab the latest code from the Source Code tab and rebuild the OopFactory.X12.dll, that's the only one you will need to update.
Feb 4, 2014 at 12:26 AM
Dear dstrubhar,
Are you planning to release a new version of the x12 parser anytime soon?

Many thanks, in advance, for all your help.
Kind Regards,
Feb 6, 2014 at 3:28 PM
I will do a release this weekend after I finish some regression testing.