We recently made the leap from manual paper 1500 claims to all electronic using Availity. Other than having to run separate X12 batches for BC/BS Florida (and manually edit the SenderID field before submitting) our other submissions (Medicare, etc.) seem to be fine. However, we can not get any of the ERA files we have gotten back from Availity to load into OpenEMR. We get the following error; “Unknown or unexpected segment ID” Does anyone else have this issue, or know what to do about this? Availity has no clue.
According to their ERA Primer, extra software is required to read the electronic remittance advice files from the carriers. They provide a link for the free Medicare Remit Easy Print application for the task.
i used availity in the past and switched to officeally, which is also a free service as long as your commercial claim volume is over 50% as compared to government claims (medicare, medicaid, etc). any given month you fall short, they will charge you $20.
the reason i made the change mostly related to the interface availity has for functions such as rejected claim search. they will send you a link that is only alive for 90 days, any older record will not be available unless you specifically call them to ask them to reload it again. office ally seems to have a better user interface.
for your info only. i do not know anything about the error.
by the way, switching clearing house is a hack of work also, so make your decision judiciously.
Availity’s graphical user interface is slicker. The last time I looked, there was no charge for governmental claims exceeding 50%, but our local Medicare carrier was not on their Payor List. On their Demo, error messages for X12 files were too technical for the average user.
The appearance of Office Ally’s website is rather dowdy by comparison. Substantively, topics are well organized and navigation is fairly easy. Support is professional and knowlegeable.
For practices in Florida to set up with Office Ally, the procedure is rather straightforward. It involves online enrollment with Office Ally and paper enrollment with Medicare, which takes 3-4 weeks and Medicaid, which takes 24 hours for a practice switching to Office Ally. ERA enrollment is included with the paper forms.
Their Payor List is the most extensive that I have come across.
The time spent on enrollment would be more than compensated by the elimination of separate X12 files to the Blues each week or month. Generally a single X12 file is uploaded unless it involves an obscure insurance company, which requires a paper claim anyway.
Thanks, we know the pain of switching, but we dumped OA for several reasons, speed and reliability primarily but that was over a year ago, perhaps they’re better now. So you have no problems uploading the ERA files you get from OA?
No 835 enrollment was done. Transitioning from paper medical records to OpenEMR and attesting to Meaningful Use was more fun and excitement one person can stand in a three month period.
I was hoping that there was an easy fix to the situation.
Then the question is, does OpenEMR have a built-in reader for those 835 files? Not everything is native, for example, the .pdf reader.
Office Ally walked us through the X12 Partners setup, via a LogMeIn connection. The Sender ID and the Application Sender Code, both of which is our Taxpayor Identification Number, have not been changed since that time. Another question that comes to mind. Does the changing of the Sender ID have anything to do with the inability to read the 835 files?
i just tried, it does read era835 file, no additional reader is required.
i still need to learn how to use that correctly. the info in era 835 seems to be pulled automatically to the frame fees–>payment, which is really handy for collecting outstanding balance of the patient’s last visit at checkin.
Thanks, it saves me the trouble of installing a reader that is not needed. Another reason to be grateful for OpenEMR. Medicaid will end paper EOB’s soon, probably Medicare will follow suit; therefore 835 enrollment will be inevitable. Medicare stopped mailing check about 1 1/2 year ago.
It “smells” like the problem requires one or two clicks to solve. The error message suggests that the reader does not recognize that the file belongs to the practice.
O.K. Hui, put on your developer’s hat. What are other possibilities and where can they be fixed?
Thank you for all your suggestions. We so need to make this work!
On Jun 30, 2013 6:12 AM, “fsgl” fsgl@users.sf.net wrote:
Thanks, it saves me the trouble of installing a reader that is not needed.
Another reason to be grateful for OpenEMR. Medicaid will end paper EOB’s
soon, probably Medicare will follow suit; therefore 835 enrollment will be
inevitable. Medicare stopped mailing check about 1 1/2 year ago.
It “smells” like the problem requires one or two clicks to solve. The
error message suggests that the reader does not recognize that the file
belongs to the practice.
O.K. Hui, put on your developer’s hat. What are other possibilities and
where can they be fixed?
Why is it necessary to change the Sender ID with each batch of Blue Shield claims?
Was the 835 one big file or separate files? If Availity sent one file back for one particular date of billing, are they able to divide the 835 into separate files for each Sender ID? If they can do that, try opening the separate files with the corresponding Sender ID.
i am thinking the “unknown segment ID” may not be referring the sender ID exclusively. i understand the x12 files has lots of “segments”, each referring different piece of info, and i assume each has a unique “segment ID”. the era835 is likely of the same format/logic. so the first thing i imagine should be to find which segment is causing the error and work from there. Calling availity is likely a good start, some of there support people is very knowledgeable.
another thing to try is to update your openemr to the most recent version and patch. i am using 4.1.1(12).
i wish i had more programming knowledge to put more back to the community, unfortunately i am more of a user.
the era835 file typically is a file that may contain one or more patients reimbursement from a particular payer to a particular provider covering a given period of time. it is grouped by the payer at their convenience, oftentimes the number of patients in one file depends on how many claims you sent in during the period to that payer.
it is regrouped by the payer and does not have anything to do with the original x12 any more.
the clearing house does not make any change (at least that is what i was told), and just pass the file to you.
After an ANSI X12 837 file has been uploaded to Office Ally, there are 2 acknowledgment reports, one from them and one from the carriers.
Insurance companies usually process electronic claims in 10 to 14 days, but they don’t do so simultaneously and therefore the 835 files won’t match the 837 files for a particular billing date, so you are correct.
It would be extra work for Availity to tease out the Blue Shield claims. If that can be acccomplished, then the question of the Sender ID can be answered.
Office Ally had a knowledge base of error codes and explanations for the 837 files. It is unfortunate that we don’t have something similar for the 835 reader.
Is there an error log that can be accessed to determine which segment is the culprit?
I’m not familiar with any error log for the upload of ERA files.
After hours of searching the forums I did find an entry by Tony McCormick who was using Availity back in 2010 and was going to port his cron code for ftps auto-submit to 4.0 but the thread has been inactive since then.
We are getting desperate, surely someone is using Availity successfully, and if so could you please post a little help here?
it is really down to which exact segment and the piece of info within that segment is not recognized, that is something to track down and then find out how that info was carried to the 835 file.
generally, the billing info is generated by openemr and sent to clearing house, then to payer, then the payer send back the 835 to clearing house after processing, then to you. something does not work well during the chain reaction, there are too many possibilities, other people’s solution may not apply to you unless the problem is exactly the same.
A stop gap measure is to phone the carriers and ask for paper EOB’s until this has been sorted out. Our local Medicare carrier will re-sent an EOB if the first has been lost. They should cooperate because this will be an one-of.
Patients don’t care if you are not prompt in asking for the balance. The insurance payment should have been directly deposited, so that should not be a big issue. Hopefully there are enough crossover claims for Medicare so that there are not too many secondary carriers left for your office to bill.
Unless you have talked to multiple individuals in Availity Support and they are all clueless, sometimes it is a matter of calling a number of times until you finally get someone who cares enough to work with you. Your situation is unlikely to be unique; so Availity should have some experience dealing with it and therefore should have a range of possible solutions.
While you are waiting for the EOB’s, the electronic fix may appear before the hard copy. Things are strange that way.
I really appreciate all the help however, reading the file with notepad is
not helping get to the cause of the problem here. I know there is
something OpenEMR doesn’t like about the Availity ERA files but they can’t
tell me what it is and I am not having much luck diagnosing it either. We
processed ERA files from Medicare before the changeover with no problems
but no such luck with Availity. Comparing the two for differences reveals
nothing obvious other than what would be expected. It seems as if there is
some common denominator between what we send out and what we get back that
is missing or incorrect. Anyone have a clue?
On Jul 1, 2013 3:17 PM, “fsgl” fsgl@users.sf.net wrote:
Instead of loading the 835 into OpenEMR, try opening it outside of
OpenEMR.
According to page 17 of the Availity EDI Guide, the file can be read with
Notepad, Wordpad or Textpad. See attachment.
I use office ally instead of availity, but I recall an upload problem I fixed by something kind of silly. In the insurance company address if I put in a zip code in this format xxxxx-xxxx it would drop the last digit because of the dash and error out the whole file. Its just a thought, but could be something hard to come across on your own.
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.