Medicare Billing via X12 submission

michaelke wrote on Thursday, January 15, 2015:

Hi All,

We are a Podiatry Practice and we would like to be able to submit X12 files to Medicare for Electronic Billing using OpenEMR to generate the file. I have generated the x12 files and received rejections from Medicare. My latest rejections involve the X12 file missing the required ICD references to go along with the performed procedures. Please assist. We were able to successfully send X12 files to Availity for billing from private insurers, our only hiccup right now appears to be Medicare. Hopefully there are some quick modifications that need to be made. IF that is not the case. We would be willing to pay something for the assistance to get us up and going. My contact information is below. Thanks.

Michael

michael_kern@kernpodiatric.com
312-226-5376

fsgl wrote on Thursday, January 15, 2015:

If View Log had been viewed before upload to Availity, log would warn that dx’s are missing.

What precisely was the rejection message (in text, not codes)?

michaelke wrote on Thursday, January 15, 2015:

Thank you for the quick response. Oh wow I don’t have the justify column in my version. Did I miss a patch? I didn’t upgrade to 4.2 yet. Well that is weird. does the Justify column add itself after you have added the icd9 codes, exit the patient, then return? I just returned to my trial patient and the justify column was there waiting for me to enter the corresponding diagnosis.

michaelke wrote on Thursday, January 15, 2015:

I will give it another go.

fsgl wrote on Thursday, January 15, 2015:

I would think that the Justify function has been present in one guise or another from the beginning.

When we sent paper claims, there always was a field for ICD’s & pointers.

The forerunner of the Fee Sheet, Charges Panel, has the Justify function as well.

michaelke wrote on Thursday, January 15, 2015:

Ok so I have attached a screenshot of the errors I am getting

tmccormi wrote on Friday, January 16, 2015:

The justify process has been there since the beginning (at least version
2.97)

Tony


Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.

fsgl wrote on Friday, January 16, 2015:

Glossary of Loops & Segments.

Error-1
Unclear if Loop 1000A or 1000B
1000A NM109 = Submitter ID
1000B NM109 = Receiver ID
2000B SBR03 = Insured Group or Policy Number

Error-2
2300 HI = Diagnosis
2400 SV107 = Diagnosis Code Line Number

Error-3
No loop or segment

fsgl wrote on Friday, January 16, 2015:

Office Ally has a section to repair claims, whereby the user can correct all listed errors from a mockup of CMS 1500.

Ask Availity about this & fix from there instead of resubmitting.

michaelke wrote on Friday, January 16, 2015:

What I noticed is that in a correctly submitted X12 file using another program our submitter ID is placed directly after the company name like:

NM1412MIDWEST FOOT CARE LTD*****46Submitter ID

Now OpenEMR creates the same line, but instead of Submitter ID use our TAX ID. It is pulling the tax ID from the Tax ID listed under the Facility information. How do I force OpenEMR to pull the submitter ID instead?

michaelke wrote on Friday, January 16, 2015:

hmmm, my post removed all the asterisks symbols

visolveemr wrote on Saturday, January 17, 2015:

Hello Michael

Based on our understanding, from error-2.pdf file (which is a 999 acknowledgement from medicare), it looks like there were two claim errors occurred for the patient ‘7062-28981’

  1. “Submitter id” is missing. It should be used when the provider directly send the claims to Medicare. Submitter ID, which Medicare provides to the provider, should be configured in OpenEMR. While claim generation (only for medicare), this Submitter ID should be used instead of Tax ID.

  2. “Insured Group or Policy Number” (2000B/SBR03) should not be used for Medicare and it must be blank.

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library

michaelke wrote on Monday, January 19, 2015:

Visolve,

Thank you for your input. My question regarding your point 1 is that, OpenEMR is pulling the TaxID from the facility information. So how would i distinguish for the claims to pull the Submitter ID number for Medicare instead of the TaxID number? It certainly would be very time consuming to keep adjusting facility information for every individual claim submitted. I am looking at this issue incorrectly? Thank you for your help.

Regards,
Michael

fsgl wrote on Monday, January 19, 2015:

Have a look at X12 837p Reference, specifically at 1000A Loop & 2310B Loop explanations.

michaelke wrote on Tuesday, January 20, 2015:

fsgl Thank you again. I understand the 1000A and 2310B loop explanations. My questions are regarding the proper location for the X12 information required being entered into OpenEMR. At this moment in time it appears that when OpenEMR generates an X12 file the TaxID information for the Billing Facility is pulled from the TaxID I had entered in Facility information. This information is used in the 1000A Loop that requires the Submitter ID for Medicare. Is that a glitch? Or Am I just confused in the location that I should be entering the Submitter ID? Hopefully my question makes a bit more sense.

Michael

visolveemr wrote on Tuesday, January 20, 2015:

Michael

Is it possible for you to upload the claim that got rejected with de-identification (you can modify the sensitive elements)?

We did further analysed on the error-1.pdf, and here goes our additional findings.

The error has also occured in the LOOP 1000B NM109, which says for Medicare (Ref: Link to zip file) “The Receiver ID in both the NM109 and GS03 must be equal”.(refer screen shot).

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library

fsgl wrote on Tuesday, January 20, 2015:

The confusion resolves around ETIN (Electronic Transmitter Identification Number) & EIN (tax id).

See this post.

The Sender ID in the x12 Setup Dialog should be populated with the ETIN assigned to you by Availity.

michaelke wrote on Tuesday, January 20, 2015:

So i’ve attached 5 files. 1 is a successful claim submitted to Medicare using our current billing software. 2 is the unsuccessful claim submitted to Medicare using OpenEMR. As you can see some of the key information required is not in the correct locations (NPI, Submitter ID, TAXID). The next 3 are snapshots from OpenEMR that is used to generate the X12 file. Please ignore the SBR03 error as well as the claim error. I resolved those with your help already. Thank you for looking.

Also, we submit these claims directly to Medicare, not to Availity first. We only use Availity for our private insurance payers.

visolveemr wrote on Wednesday, January 21, 2015:

Michael

While comparing the files, medicare code doesn’t match (1000B NM109 and GS03) in unsuccessfull file, and it is same in successful file.
please follow our previous steps to resolve it and share your comments.

For your additional information (error-2-2.pdf),

1, No ICD found (HI Segment)
2, ICD mapping not found in SV1 (SV107)

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library

visolveemr wrote on Wednesday, January 21, 2015:

For your easy understanding, here goes the different errors you’ve faced and the solution discussed.

From error-1-2.pdf

  1. Error: Loop 1000 B - NM109 [Implementation Pattern Match Failure]
    Issue: For Medicare (Ref: Link to zip file) “The Receiver ID in both the NM109 and GS03 must be equal”.
    Solution: Match the value in GS03 and ETIN same in X12 partner for medicare.
  2. Error: Loop 2000 - SBR03 [Implementation Dependent “Not Used” Data Element]
    Issue: SBR03 should not be used for Medicare.
    Solution: To remove the same

From error-2-2.pdf & error-3-2.pdf

  1. Error: Loop 2300 - HI [Required Segment missing]
    Issue: ICD is not included in the claim
    Solution: Include ICD in FeeSheet

  2. Error: Loop 2400 - SV107 [Segment has data element errors]
    Issue: ICD is not associated with CPT
    Solution: Associate ICD with CPT in FeeSheet

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library