X12 ISA 05 and ISA 07

midder wrote on Tuesday, April 12, 2011:

Hello

We are using Open EMR V3.2.

We are trying to submit claims to Office Ally. In doing so, they are informing us that we have ISA 05 and ISA 07 errors. Comparing the files that were generated from Open EMR to what I was given as a valid example, I see these differences:

ISA*00*          *00*          *ZZ*12-345678     *ZZ*123456789      * <- Good
ISA*00*          *00*          **               **               * <- Bad

How do I get the ZZ and the numbers following them to show up on the file that is generated from OpenEMR? I have Office Ally setup as a partner under X12 Partners with the ID Number (ETIN) and Receiver ID (ISA08) filled out as I would expect to see them on the generated file. But OpenEMR is not filling these values in the file.

Can anyone offer a little guidance on this?

Thanks
Brian

tsvas wrote on Tuesday, April 12, 2011:

Did you try ISA05 and ISA07 as “Mutually Defined”?

midder wrote on Tuesday, April 12, 2011:

Sorry I should have specified that. Yes ISA05 and ISA07 are both set to “Mutually Defined”

tsvas wrote on Tuesday, April 12, 2011:

If you can paste here all the fields (ofcourse xxx ETIN), I can compare with my working system and let you know.

midder wrote on Tuesday, April 12, 2011:

Thank you for your assistance. Do you mean the configuration values from the partner screen? If so, here they are:

ID Number (ETIN): xx-xxxxxxx
Receiver ID Qualifier (ISA07): Mutually Defined
Receiver ID (ISA08): 330897513
Sender ID Qualifier (ISA05): Mutually Defined
Sender ID (ISA06): xx-xxxxxx <- Same as ETIN
Acknowledgment Requested (ISA14): No
Usage Indicator (ISA15): Production
Application Sender Code (GS02): xx-xxxxxx <- Same as ETIN
Submitter EDI Access Number (PER06): <blank>
Version: 004010X098A1
Processing Format: standard

aethelwulffe wrote on Tuesday, April 12, 2011:

Are you sure that it should not be Duns and Bradstreet instead of mutually defined?
Processing format is cms?
is gs05 the correct number of digits?
cms id in insurance company
payer type set in insurance company?
Office ally set as the x12 partner for the insurance company in the insurance company set up/configuration?

tsvas wrote on Tuesday, April 12, 2011:

This is how I setup in V4.0 (after upgrade from V3.2, I didn’t make any changes in V40:

ID Number (ETIN): xxxxxxxxx (No dashes. Not sure if dashes makes any difference. I need to look at code.)
Receiver ID Qualifier (ISA07): Mutually Defined
Receiver ID (ISA08): 330897513
Sender ID Qualifier (ISA05): Mutually Defined
Sender ID (ISA06): BLANK
Acknowledgment Requested (ISA14): No
Usage Indicator (ISA15): Production
Application Sender Code (GS02): BLANK
Submitter EDI Access Number (PER06): BLANK
Version: 004010X098A1
Processing Format: standard

aethelwulffe wrote on Tuesday, April 12, 2011:

Ooops, Duns is 01, not ZZ…
  Look to your Insurance company set-up and make sure it is configured to the correct x-12 partner.  Either that, or the x12 partner in the billing list is not selected for the claim (I have seen that after an x-12 partner update in 3.2, the x12 box in the claim was still blank.
  Other issues Possible:
     Patient does not have insurance accurately set (unlikely if x12 partner shows up in billing list)
    Insurance company not set up for partner (this one got me).
    x12 partner just not selected when producing a claim.

midder wrote on Tuesday, April 12, 2011:

I know that Office Ally is set as the X12 partner for the provider. I’ll have to check on the patient/insurance side.

Thank you both for the tips. I’ll report back my findings.

midder wrote on Tuesday, April 12, 2011:

A quick update:

- For the insurance CMS ID, the value is blank
- Payer Type is Other HCFA

What values should be in there?

midder wrote on Tuesday, April 12, 2011:

Another quick update.

I found that files generated today did indeed have the values in them: (*ZZ*12-345678     *ZZ*123456789)

So perhaps the issue was as aethelwulffe suggested and the previous claims did not have the appropriate defaults set at the time of submission. I’m hoping that subsequent files will have all relevant data, as required.

Office Ally takes a while to let us know what the result of the files was, but I think that this was the issue.

Thanks for the assistance.

aethelwulffe wrote on Wednesday, April 13, 2011:

CMS id should be the cms id for the insurance company…

Here is a list of numbers for some companies. 
http://www.eclaims.com/payerlist.asp?action=desc_results&displayresults=Y
Type is cms if it is medicare/medicaid,  and different for different companies/plans (all of ours are cms)…  Of course you should talk to the insurance company (maybe not clearing house) to determine payer type.

aethelwulffe wrote on Wednesday, April 13, 2011:

PS, expect lots and lots of other issues.  Patient gender, insurance numbers, DOB, subscriber info….everything will be wrong wrong wrong… :)  But you will work it out, with some help perhaps.
   Eventually you get to the fun part, which is checking eligibility before appointments even happen, then you are more assured that the claims will go out clean.(via a 270 file).

bo2999 wrote on Wednesday, April 13, 2011:

You can upload to Office Ally using HCFA 1500 TXT format.  Just ask them to map the fields one time. It only took them 2 mins to do it for me.

-bo

mkup wrote on Monday, May 02, 2011:

aethelwilfffe, are you saying that eligibility batch is unusable? Insurance payor number, patient gender is not in the 270 file - I tried 4.0 and 4.1 dev demos today. What’s even scarier is that the resulting file only has data on the first insurance plan on the list.

I think I saw your fix to eligibility batch at some other forum thread… Do you know if it’s been incorporated in the current dev instance?

mark

aethelwulffe wrote on Monday, May 02, 2011:

No, I have no fix for eligibility.  Someone else is developing that.  I only have some changes that allow you to configure some other header elements for your x12 partner and makes them a little more understandable, and that has not been incorporated.  I have been working on some “got to or we die” grant writing stuff and have not been keeping up with what may be available in current mods and patches.