leongruenbaum wrote on Thursday, March 10, 2016:
ah - now i found that page you wanted. i can see clearly that the top one - a different patient with a non-problematic provider - has both provider and x12 partner filled in, in contrast to the bottom two, both of them the GHI patient, where neither of those fields is filled in. so the question is why is that (automatically?) filled in for the oxford patient but not for the GHI patient in this particular case
fsgl wrote on Thursday, March 10, 2016:
Last screenshot from the Billing Manager was most helpful.
Patient 383’s 2 claims failed because X12 Partner was blank, unlike that for the patient with Oxford. Didn’t help to have no insurer either.
The X12 dialog for Post-n-Track looks a little strange, but if it works for the other claims, cannot argue with success.
O.K., mystery solved.
Do the following:
When you have some free time, you may want to consider switching to Office Ally because Empire Blue Shield claims are free to submit (see attachment). They also have very good support & their scrubbing software (sort of like DooDad) is excellent.
Their Payor List is extensive; so in all likelihood, one stop shopping. Even if some of your insurers are not participating with Office Ally, it’s only $19.95 per month at worst. Sure beats all the aggravation we get from our local Blue Shield, who doesn’t participate.
leongruenbaum wrote on Thursday, March 10, 2016:
Thanks
am not at the machine now but will check what u have written. certainly it makes sense theyd come out blank given that the fields are blank
however as i say, some ghi’s and some Empire plan’s do work. doesnt really make sense, right?
fsgl wrote on Thursday, March 10, 2016:
It makes sense if the billing person is not selecting the insurer & X12 Partner from the drop down menu in Billing Manager before clicking Generate X12 or if the Insurance Companies are not set up correctly.
Good idea to run the error log before sending 837P to clearinghouse. Lack of insurer, X12 Partner & other missing data will be detected by the error log. See attachment 2.
I presume “Empire” is the Empire Plan, division of Unitedhealthcare; not Empire Blue Shield, a subsidiary of Anthem. No question that the Empire Plan (out of Kingston) is free because Unitedhealthcare is commercial.
Sometimes the Blues are free & sometimes they are not; but Blue Shield for the New York metro area is definitely free as depicted in my prior screenshot
aethelwulffe wrote on Friday, March 11, 2016:
Yep. Got code. Friday is the ‘dust off projects, make a go of it’ day, since that is the only day of the week we are not in full swing with PQRS.
aethelwulffe wrote on Friday, March 11, 2016:
You made sure that the billing manager shows an x12 partner for that particular visit, right? If it got clicked off, that could be an answer.
I guess I could check your screenshots too.
EDIT: I don’t have a screenshot of the claim for your billing manager, but this sounds EXACTLY the sort of thing that would happen if someone accidentally clicked the x12 partner and changed it from the default for the insurance company just for that claim in the billing report.
That would mean there is no x12 partner, thus things defaulted to 4010.
aethelwulffe wrote on Friday, March 11, 2016:
https://github.com/aethelwulffe/PQRS_Gateway/tree/x12_4010_smackdown
Made 837 files 4010 standard free.
leongruenbaum wrote on Friday, March 11, 2016:
going to check it out right now.
btw do u know if office ally software is compatible with windows 10? our machine has been getting a lot of pressure to update. (and doodads (postntrack) is not yet compatible, supposedly). the updatemight happen without our wanting it(!)
leongruenbaum wrote on Friday, March 11, 2016:
attached - a few more screenshots. both ghi and Empire Plan (yes i was referring to this, not bcbs) have postntrack as their x12 partner
and then i did as u said - selecting this patient ID in billing manager. i do see where when i do that that x12 partner is not selected, and i can select it. however, provider is also blank (“Unassigned”) and i cannot select anything in that dropdown. i am guessing if i did generate an x12 it would be closer to what we need but still not pass muster if it is missing the provider, right?
btw is it necessary to have a group number, btw? my client is unsure on this point
leongruenbaum wrote on Friday, March 11, 2016:
btw i am not getting email notifications of answers to this thread - how do i do that? thanks
leongruenbaum wrote on Friday, March 11, 2016:
i’m having the client check that those two fields are filled in on GHI and Empire Plan before she pressed generate x12, but i’m pretty sure we will see a one to one correlation between when they’re both filled in and when we have success. just now she did an empire plan one and it did fill in automatically and it appears to have been successful. the mystery STILL to me is why some don’t fill in, and worse, i don’t think we will be able to fill in the provider even at that last step before pressing x12 if it hasn’t filled in properly automatically. let me know if u can think of any other reason some patients would differ from others in this respect, thanks
fsgl wrote on Friday, March 11, 2016:
I think the source of the mystery lies in the original setup of Insurance Companies. Often a practice will assign this task to the most junior staff member. If she had been in a big hurry during setup, it’s just a matter of time that problems will ensue.
The screenshots about Empire & GHI contain wrong data. Empire is in Kingston, not New York City. If a paper claim is sent & USPS’ optical scanner cannot read the zip code; the claim will go to the wrong place. The Payer Type is not Other HCFA, but Commercial. Box 1 of the CMS 1500 makes this distinction. An insurer can reject the claim for this simple error. The CMS ID or Payor ID for GHI is either 13551 for the PPO plans or 25531 for the HMO products. 135511997 will cause routing problems.
The Practice module has no Delete button. As a result an insurer with wrong data can only be corrected by typing over the mistakes. If the practice has an entry for an insurer with no name nor X12 Partner (see 1.png) & this ghost insurer is chosen by the billing clerk; claims in the Billing Manager will have no insurer nor X12 Partner.
A senior staff member must review all Insurance Companies for errors & check that no ghost insurer had been selected for any patients.
It would be a good idea to delete ghost insurers from the Database, see 2.png. Do not delegate this to the client because they may end up toasting OpenEMR. Please remember to backup before changing the Database.
Group numbers are important in routing claims. If the patient has Empire from New York State employment, the group number is 0030500. Both Empire & Unitedhealthcare have the same Payor ID (87726), so the group number helps to get the claim to the correct subsidiary.
Clearinghouses generally don’t care which operating system your client uses as long as the 837P’s & CMS 1500’s are relatively error-free.
But I would strongly advise against the use of Windows 10. If a user has no concerns with all his personal data being relayed back to Microsoft’s servers, that is his prerogative. U.S. practices don’t have this option because doing so constitutes breaches of HIPAA. One big, fat fine can mean the demise of the practice. New York State confidentiality laws are even more stringent than HIPAA.
To get rid of the annoying “Get Windows 10” applet in the system tray, do the following:
The email notifications are not dependable. They don’t work, when you want them & they do, when you’re not interested. Just keep your eyes peeled for relevant threads.
leongruenbaum wrote on Friday, March 11, 2016:
ah ok - this is super helpful. will probably be next week before i attempt again but this looks to be a strong candidate for this resolution of the issues
thanks
leongruenbaum wrote on Monday, March 21, 2016:
hello -
Hoping “good luck” Isnt your way of ending the conversation haha
I sent to post n track what u wrote about what we had wrong in our insurance info
he wrote:
Hi Leon,
Here are the payer IDs we have under the Emblem umbrella:
EmblemHealth
GHI – New York (Group Health, Inc.) 135511997
GHI HMO - 255311997
HIP – Health Insurance Plan of Greater New York - 552470001
Vytra Healthcare - 222647447ConnectiCare (VIP Medicare Advantage) – 783750001
You must use one of those values. Other than that, it doesn’t really matter to us how you setup your own billing system. Let me know if you have any other questions.
Curious how that squares with your idea of what those values should be. I mean, you mention other values for GHI - depending on whether it’s HMO or PPO. actually my client says she isn’t really being careful about checking whether it’s HMO or PPO, but i’m sure she ought to be. are you suggesting, then, to do this properly we ought to have two separate GHI insurance companies, one for HMO and one for PPO. each w its own Payer_ID?
Anyway i’m sorry to say she hasn’t submitted enough GHI’s or "Empire Plan"s recently to give us an idea of how it’s working now. i have seen where throughout the history sometimes each of those has worked and sometimes each has failed. It’s not clear to me how a general value in the insurance company table would make one patient work and another not, unless she is making a gross error such as not selecting an insurance company for that patient. (but i am pretty sure i have seen that she always enters an insurance company).
well, if you have any thoughts, let me know - the truth is i probably need to see more examples of its working or not to get an idea what’s really happening
leongruenbaum wrote on Monday, March 21, 2016:
btw i checked the log in the billing manager and i do see where some of these ones that aren’t going through say "*** Error: Insurance information is missing! ".
this seems to verifiy our current theory, i guess - well i hope to have more data soon
fsgl wrote on Tuesday, March 22, 2016:
We’ll stay with you to the bitter end.
If the client has only 7 insurers & there is no ghost insurer, that eliminates one source of error.
Strange that Post-n-Track assigns 9 digits to some of their payor id’s. Clearinghouses usually use 5 digits & they don’t vary between clearinghouses . If they insist upon their own payor id’s, there is no choice in the matter.
“GHI – New York (Group Health, Inc.) 135511997
GHI HMO - 255311997”.
The first is for PPO. Client should have 2 GHI’s set up to avoid routing problems.
Did you have the opportunity to watch the client when she corrected the 2 claims for patient 383? It would have instructive because working backwards would have offered clues to the source of the error.
If not, you will have to log into their system when she corrects the blanks. Usually it’s something simple & which the client is doing that is slightly different from the normal routine.
It still sounds like a setup problem.
fsgl wrote on Tuesday, March 22, 2016:
When we send our claims to Office Ally, none of their software touches our 837P files until they are uploaded to their website. This is true for other clearinghouses that we’ve worked with in the past.
Not knowing how exactly DooDad interacts with your data before the Generate X12 buttton is clicked, I wonder if there might be some sort of conflict.
Because there is no GHI setup for patients with HMO coverage, can this be the reason for the blanks in Billing Manager? Does DooDad have anything to do with this?
fsgl wrote on Tuesday, March 22, 2016:
Have a look in the error log (xampp\php\logs\php_error_log) on the day that patient 383 had the 2 blanks in Billing Manager for any clues.
leongruenbaum wrote on Tuesday, March 22, 2016:
ok - will check out that log later. unfortunately i am with the client only a few hours a week. anyway, i really appreciate your advice on this.
is that error_log the same as i get in billing manager? basically, in that billing manager log for the times when those 2 fields weren’t being filled in i saw the error "Error: Insurance information is missing! " that i reported before
btw - actually when i looked at that log i saw there was another error that occurred a few times “*** Procedure ‘97803’ is not justified!”.
is this familiar to u at all? the client says it’s a “procedure service code”. (and it’s unrelated to our other problem - this is AETNA, which has never been an issue)
see attached - here’s what’s a little unusual. the top one gave that error. we resubmitted - the bottom one - and this time it worked. but u can see a slight difference in that the bottom has (ICD10/E66.9) following the 97803. (and in fact that same code - with that parenthetical comment - was used in 3 others, all of which worked, i believe.)
to tell you the truth, this AM I saw her computer was nearly frozen and i rebooted it. i’m beginning to wonder if somehow there are running-out-of-RAM type issues, and that those could be causing random weirdness. til we resolve this i’m going to have her reboot each morning.
thanks