X12 ISA segment availity claims

I see, what is availity expecting here? Do you know?

a valid ISA is the issue, you have 2 dates with one having a leading 1

Hmmm, I am supposed to have only one date?

ISA*00*          *00*          *ZZ*               *ZZ*               *220928*1427*^*00501*000496488*0*T*:~

test file generated from OpenEMR Login

1 Like

Can you tell me if my X12 entry above (the pic above) is correct?
Should I eliminate the ID number then?
I gathered those numbers from reviewing the wiki and the forums


have to fix the underlying issue, shouldn’t hand edit X12 files

oh you weren’t asking that :slight_smile:

yeah, that looks fine, seems like there’s an issue with your codebase still

1 Like

ID number (ETIN) should be your availity customer number ID. Sender ID (ISA06) should be AV09311993. Application Sender Code (GS02) should be 5010. I had not used the Submitter EDI access Number (PER06), I have always left it blank.

1 Like

Thanks so much for replying


“ID number (ETIN) should be your availity customer number ID”

For some reason I thought it was availity’s TIN

1 Like

This is what I have been doing and it has been working. Inside availity under User’s account. The drop down menu has a Manage My Organization item. When you click on it, the left panel has a Customer ID listed under the organization of interests name. Use that one. That being said, there may be more than one way.

1 Like

Yes, I went to availity and I actually found it. Thanks. I will give it a try

Thanks again

1 Like

Can’t wait to hear of your success!

1 Like

I don’t think that’s the problem with the generation of the X12 however will probably be helpful later.

Ok, I see what happened here.

Finally, a one-patient batch has been submitted successfully!

When you compare the correct ISA (top) vs my ISA (bottom):

ISA*00*          *00*          *ZZ*               *ZZ*               *220928*1427*^*00501*000496488*0*T*:~
ISA*00*          *00*  *ZZ*AV09311993     *01*030240928      *030911*1220928*0944*^*00501*000197922*1*P*:~

We can see the problem is that my ISA04 has only two blank spaces. Availity requires 10 blank spaces at that position. This means, OpenEMR fills in rubbish characters downstream, hence the “030911*1” that my file has.

I did not know I needed to map my X12 partner file for availity and enter spaces and all (I may have known once, but forgot). So in my ISA04 I had two spaces, not 10.

There that was the problem.

Here is the most recent EDI companion handbook for Availity (updated 8/2022):


ISA segment mapping table starts at page 53

1 Like

great debugging

we can add some padding to those fields when it’s saved to prevent this going forward

1 Like

Hmm, yes, my question is, do all clearinghouses have the same requirements?
In other words, page 53 of the availity edi_guide reflects the standard or is it just for availity?

yes, the ISA has a fixed record length, should have mentioned that earlier :slight_smile:

it’s exactly 105 characters so the separator fields can be parsed at the end

1 Like

Right, but more specifically:
ISA 01 → “00”
ISA02 → 10 blank spaces
ISA03 → 00
ISA04 → 10 blank spaces
ISA05 → “ZZ” (otherwise known as “Mutually Defined”)
ISA06 → "AV09311993 " ( or AV09311993 + 5 blank spaces)
ISA07 → “01” (or Duns & Bradstreet)
ISA08 → "030240928 " (or 030240928 + 6 spaces)

Are these zeros and blank spaces an industry standard or specific to Availity?

Oh, I see!

it’s industry standard that certain fields have certain widths, ISA (Interchange Control Header Segment) | CMS 1500 claim form and UB 04 form- Instruction and Guide

1 Like

So, should the user be entering the spaces in the X12 partner section?

It makes it very complicated.

I’m not saying it should be done by the code either. Because it could get changed in the future

if you don’t edit that field it saves it as 10 spaces

certain fields will have to be padded to prevent what you discovered

pretty sure this spec won’t change these things

1 Like