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
thanks
have to fix the underlying issue, shouldn’t hand edit X12 files
oh you weren’t asking that 
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
Huh?
“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):
https://www.availity.com/documents/edi%20guide/edi_guide.pdf
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
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