fsgl wrote on Tuesday, July 02, 2013:
Found an old thread which may be helpful. The internal search engine is not quite as good as Google’s.
In the ERA Files on v3.2.0 thread, direct your attention to the posts of Art Eaton, 12/15/10 (second) and Kevin McCormick, 3/13/12.
hitechelp wrote on Tuesday, July 02, 2013:
Thanks for the link it was helpful. After comparing two files sent back to back each with one claim, we noticed that ISA13 (file control #) segment is not incrementing. We keep sending the same file control number! It should be unique for each X12 file. Now I just need to find out how that works and fix it! I’ve searched the gen_x12_837.inc.php file but I’m no Php guru and haven’t found where this comes from. Clues anyone?
hitechelp wrote on Tuesday, July 02, 2013:
Hold everything. Seems the biller was sending the same file repeatedly.
xiaoanri wrote on Wednesday, July 03, 2013:
i checked a few of our x12 and era835 files, ISA does not seem to increase. i could not find the segment “ID” either in our 835 file.
if you were able to load medicare 835 file in the past, try to pick up exactly the difference in the file as compared to the availity file, and study each carefully, try to change each to format of medicare file and try upload again…
you need to find which one piece of data is causing the issue. remember the computer is not as smart, any subtle difference, such as a hyphen, space, punctuation… anything could be the cause.
hitechelp wrote on Wednesday, July 03, 2013:
We only have two payers set up on Availity for now. MCR & BC/BS. Our
999’s, and acknowledgements indicate MCR is getting accepted (and paid)
837’s are fine except for FL BC/BS which is a known issue, we get an
invalid sender ID error from Availity for them.
Sorry for the miss-Que but we’ve always been able to open and edit any
835’s with Notepad++.
On Jul 2, 2013 5:57 AM, “fsgl” fsgl@users.sf.net wrote:
We have clues, just not the solution.
Did you get a separate acknowledgment file that all your claims had been
accepted by the payors? Is there a problem with the 837 as well?So you can’t open the 835 outside of OpenEMR with anything else? Windows
will go online to search for another application. Did you do that? If
Windows failed to find another application, try opening the file with the
Medicare Remit Easy Print from my initial post.If your frustration has reached the unbearable level, consider emailing
Rod Roark, rod@sunsetsystems.com or Tony McCormick, tony@mi-squared.com.
Rod worked on the Billing module. If you are having a problem with the 837
as well, professional support may need to look at your system directly.If you are a DIY-er and can’t bear the thought of paid help, then ask for
the paper EOB’s and switch back to Office Ally. Office Ally may have warts,
but at least you were able to open their 835’s.Availity ERA (835) file upload errorshttps://sourceforge.net/p/openemr/discussion/202505/thread/50f3ec2f/?limit=50#7152
Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / HelpTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net
fsgl wrote on Wednesday, July 03, 2013:
Thanks for the additional details. This is reminiscent of Agatha Christie’s mysteries, where there are not enough clues, so the reader rarely is able to figure out who done it (tongue in cheek).
At least we getting closer to identifying the problem and hopefully to a solution.
After Office Ally set up the X12 Partners module, our Sender ID has been constant irrespective of payors and immutable to this day. I don’t understand why it is necessary to change the Sender ID for Blue Shield claims. Your office, the sender of the claims, is the same entity whether the claims are sent to Medicare, Blue Shield, Oshkosh or Timbuktu.
Did Availity tell you to use a different Sender ID for Blue Shield? What is the rationale?
If the Blue Shield 837 has errors, there should be no corresponding 835; therefore no loading into OpenEMR. Thus it’s really an 837 problem rather than an 835 problem.
zhhealthcare wrote on Wednesday, July 03, 2013:
ERA parsing problem may happen because of the presence of new line characters in that file. If you are using windows please do the following , which may reveal the issue.
save the file and try to upload this file.
Eldho
ZHServices
hitechelp wrote on Thursday, July 04, 2013:
Thank you Eldho, the line feeds were the problem. ERA uploads are working.
On Jul 3, 2013 6:39 AM, “ZH Healthcare” zhhealthcare@users.sf.net wrote:
ERA parsing problem may happen because of the presence of new line
characters in that file. If you are using windows please do the following ,
which may reveal the issue.
- Down load and install Notepad++
- Open the Era file with this software
- If you are seeing the ERA file line by line that means it contains
new line characters.- You can also verify it by ticking view->show symbol->Show all
characters. You could see CRLF or LF in black back ground.- if this is the case go to search->replace (select the search mode
as Extended( lower left hand side) then type “\r” in the find column and
keep blank the “Replace with” column. dont forget to keep the cursor in the
beginning of file before starting replace.- After this type “\n” in the find column and keep blank the “Replace
with” column.save the file and try to upload this file.
Eldho
ZHServicesAvaility ERA (835) file upload errorshttps://sourceforge.net/p/openemr/discussion/202505/thread/50f3ec2f/?limit=25&page=1#773b
Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / HelpTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net
hitechelp wrote on Thursday, July 04, 2013:
Apparently Florida Blue has some unique issues and OpenEMR does not play well with them. This link has the details. https://sourceforge.net/p/openemr/discussion/202505/thread/d5fcaae1#b3a3
fsgl wrote on Thursday, July 04, 2013:
This thread answers the question about why Availity requires the repetitive changing of the Sender ID. If the Payor ID and the Provider Number had been populated correctly in the respective modules, that should be enough.
After checking the EDI manuals of a number of Blues, it appears that the other Blues are content with the Electronic Transmitter Identification Number but Florida insists upon the use of their assigned Sender Code. To add to the confusion, ETIN denoted Employer Tax Indentification Number in the past for filing 1040’s, but is now EIN. Florida Blue Shield is wacky.
If Office Ally is able to accommodate this difference, that is almost a reason to switch back.
hitechelp wrote on Friday, July 05, 2013:
The last word on Availity and BC/BS FL. Anyone using Availity will need to;
Edit their X12 submissions to BC/BS FL to replace the EIN number in the 1000A loop
with the BC/BS Sender ID given to you by Availity.
Set Mailbox Options to allow ERA files to upload properly.
Logon Availtiy, EDI File Management > EDI Reporting Preferences > Mail Box Options You must uncheck the box next to “Start each segment in X12 files on a new line”
fsgl wrote on Saturday, July 06, 2013:
Nice to see that the 835 problem has been definitively resolved.
Isn’t the purpose of automation so that human beings don’t have to do repetitive tasks?
Another thought, instead of adding another facility as suggested by Kevin (which did not work because the Tax ID number popped up again), how about another X12 Partner with the Sender Code replacing the ETIN then changing the X12 Partner default for Blue Florida to Availity-Blue Florida?
If it works, no more fooling around with the 837 prior to sending it and there would nothing extra that the staff will need to do (making it foolproof).
If it does work, it would be helpful to post it in the other thread too.
hitechelp wrote on Saturday, July 06, 2013:
We tried creating another X12 partner but that doesn’t fly. Here’s my analysis of why:
And obtw for anyone reading this, please let me know if I am off base here because I’m not a developer, just an old school html guy.
Here goes…
The Gen_X12_837 file pulls the TIN from one of two different variables depending on whether you are using ECLAIMS as your clearinghouse or not. They are clearingHouseETIN or billingFacilityETIN, which are entered in your X12 Partner setup and Facility settings.
The only way to get the BC/BS in the right place (1000A Loop) is to create another facility and use the BC/BS number as the TIN and if you do that, the BC/BS number will replace the TIN in the 2010AA loop which is supposed to contain your TIN. So Availity kicks the whole file back.
I believe a mod for the X12_Gen based on the “if / else” statement used for the ECLAIMS EDI workaround could be developed if I could find a variable that would identify BC/BS claims and insert the Availity assigned sender ID number into all the 1000A loops instead of the TIN, and leave the other loops alone. I have tried using variables such as payerName and (clearingHouseName - along with a new X12 partner with identical Availity data with a different name) but I have not been able to get them working.
This scheme may require running BC/BS FL claims separately however, we do that anyway for ease of claims tracking. I am looking to eliminate any manual intervention which as you pointed out, defeats the purpose of automation, and also introduces possible errors.
How about it you code gurus, any suggestions?
aethelwulffe wrote on Sunday, July 07, 2013:
WE bill bcbs in florida through Availity.
We have been at this for quite a while, getting and using a Vendor ID from availity for openemr (you can find this on the oemr.org forum). A big part was getting our facilities (which provide group NPI and place of service code) the insurance companies set up properly (BCBS CMS# 00590) selecting Payer Type as Blue Cross/Blue Shield, and ensuring Availity sends ERA’s as mulit-line. If you have era’s that have line endings, you can use the “ERA Distillery” application (posted here somewhere in the mash-up, but more easily located on the OEMR.org forum) to process any number of those files automatically.
Send me a PM, and we can get together on the phone and work out your issue, either by work process or code logic, if your situation is somehow drastically different than mine and really is an edge case in some fashion.
aethelwulffe wrote on Sunday, July 07, 2013:
OK, now that I think on it, there are still some differences with my genx12 and parse_era from the code base, as well as the use of Insurance Numbers in the provider configuration (Practice/insurance numbers tab). They are NOT BCBS specific though.