Error unbundling X12 837 Professional

Apr 2, 2013 at 5:48 PM
Edited Apr 2, 2013 at 5:49 PM
Dear Dstrubhar,

Some of my X12 837 Professional (5010) files are failing to unbundle with the following exception. I get the same error using the latest 2.3.4 release. Is there anything in the raw file I can change to get this to work?

NOTE: The email editor seems to remove the asterisk symbol.

Unhandled Exception: OopFactory.X12.Parsing.Model.TransactionValidationException:
Segment 'CAS(asterisk)CO(asterisk)45(asterisk)17.27(asterisk)1' in segment position 41892 within transaction '4275' cannot b
e identified within the supplied specification for transaction set 837 in any of the
expected loops: 2000A[2136],2000B[2146],2300,2400.

As always, your kind help is very much appreciated.
Kind Regards,
Apr 2, 2013 at 6:05 PM
Did this work in the previous release? This shouldn't have changed in the last 2 years.

It looks like the parser is looking for the CAS in the 2400 loop, but the CAS needs to appear after a SVD in loop 2430, or after SBR in the 2320 loop.

If this is a file you are receiving and the sender cannot fix this, than you inject your own specification that allows the CAS at the 2400 loop. Inject your own specification.
Apr 2, 2013 at 6:17 PM
Dear Dstrubhar,
Thank you so much for your prompt response. I get the same error with the previous version of the X12Parser as well. I just tried the new version (03/31/2013) because I happened to find one available on your home page.

I will contact the sender and hopefully they will fix it. But I am going to try injecting the spec based on your suggestion... just so I know how-to do this in future.

Once again, many thanks for your help!
Kind Regards.
Apr 8, 2013 at 10:52 PM
Dear Dstrubhar,
I received the a response from the sender. According to them, Secondary claims will contain the CAS segment that reflect how the primary payment was remitted.
Claim level CAS (Claim Adjustment Segment) do come before the first SVC service line segment. Line level CAS are always after the SVC in the file. Some insurance utilize claim level CAS. While not normal, it is allowed. You should anticipate this in the data. Note that the CAS in the 837 may not be relevant to your study.

Based on that it appears they don't see anything wrong with the data, right? What is your recommendation on how I should proceed?
Thank you very much.
Apr 8, 2013 at 11:23 PM
According to the 837 specificationthe claim level CAS should be in loop 2320 which occurs after a SBR. According to your error message it appears that this CAS was at the line level, so should have been after a SVC segment.

I can't guarantee that everyone adhers to the x12 standard as it's printed, I know I've come across plenty of example X12s that didn't follow the specification that was in the same document.

Rather than argue with your sender with whether their data is wrong or not, your two options are to inject your own specification. You should be able to copy the one in the source code and make your own which allows the CAS at the line level, or you can use the new feature to only throw a warning and this will automatically get parsed at what ever loop level it is currently at.