I’ve done hundreds of these and have never seen this happen. What browser and versions are you using?
The other stuff I don’t understand. Are you also using front payments and/or EOB posting after batch payments to fix batch payments or what is your workflow?
I need more to go on please.
@jjalb This is following your workflow so you see it can work. I’m using only batch payments. What is different is what we need to figure out.
The amounts 0.00 not showing is written that way by original author because query specifically excludes 0 payments and setting to empty for some reason. I’m hesitant to change. In reality, all the 0 payment is doing is advancing insurance to next level and making a note why. Again the AR entry reflects the amounts correctly.
I don’t know what to fix!
Thanks for peeking back under the hood on this.
There are two ways to access this EOB Invoice screen -
Reports>Collections; Enter search criteria and select the invoice in question. (Method used in my example)
and alternatively a differenct direcxt to what appears to be the same screen:
Fees>Posting Payments search by patient name/etc and pull up the EOB Invoice.
Ref this in graphic 06 - I am currently resetting the reflected “0” to a -1 in the statements sent field or whatever is needed. Of note and IIRC, there have been a few instances where the primary payer denied repeatedly and each time the denial was posted in the way the status ticked down from -2 to -1 and finally to a zero. I haven’t caught this happening since we now only accept traditional medicare and never have issues with their claims but I’m mentioning it as an extension of this issue we find with the secondary denials.
I presumed just on logical flow that marking the tick box as follow up on posting would do something to the effect of preventing the advance of a claim forward to the next insurance level since an actual claim payment was zero “and” tick box was not “null” and there was a narrative in the follow up reason.
The EOB Invoice panel that already exists could be probably used to add this - all of the pertinent payment data on the claim already exists.
I agree and we dont need to “fix” one thing and break a dozen others - we’ll keep hammering on this and narrowing it down - I’m glad to test.
In your example below - the payment from Orange Colors Inc - did you enter that as a $0 payment or leave it blank? And, does this patient have a tertiary ins? I see one primary payment dropping the -3 to a -2 (correct), and then a non entry/denial dropping to a -1 (dropping to the tertiary here). This would be the same scenario I walked though except with the addition of the tertiary - it would drop to the patient balance instead.
To eliminate any differences in server environments - if you have a test server I can log into and walk through this it might be helpful to take out as many variables as possible. If it’s something my system is doing differently/incorrectly we might be able to pick it out vs changing code and give you a chance to review the code as it applies.
Yes and yes. You have to enter a payment value of some value or it will error and not allow allocate.
Second, I did have a tertiary insurance so that is the difference between us. So using patient with only primary/secondary then ins advances to patient due.
However, this is what it’s supposed to do! The only problem I see here is user shouldn’t need to select insurance company where only the insurance company for the patient’s insurance level should be allowed. In my test, I could use any insurance company. Imo, that shouldn’t be allowed.
So help me get the jest here: You want to record that the secondary denied the claim but keep insurance level at the denied insurance level(Ins2) so you can submit a HCFA 1500(or such), true?
I would think the place to do that would be a billing note rather than recording a 0 payment.
i.e
Resetting statement count should not effect last level closed. But on this, like so much other in billing, I’m unsure.
Simply said, this to me appears to be working as designed however, I don’t do billing so I can’t be sure.
Maybe @stephenwaite or @juggernautsei have an opinion.
And thanks for getting back to me. I slept in today…
This is correct in the scenario I posted. A denial can be for a bounty of other issues - insurance companies in NA are a persnickety bunch regardless of the rules even up to delays in payments to meet measures internally… When a $0 payment is received sometimes it is included in a batch of other payments from the same secondary that weren’t at $0 so it is unavoidable. This is the accounting portion of the system and I’d be interested to hear how others deal with posting and keeping track of non payments absent of them becoming lost. Aside from writing off lost revenue or passing the due balance onto the patient, there has to be some sort of mechanism in place to prevent this.
Oddly it appears to - I don’t know how these triggers are set up being a non developer but I came across this trying to find a workaround.
Np! I saw your last post was a late one - I hoped it was due to a time change and not actually 3 in the monrin…
I am sorry this took so long to get back on - I needed some available time and bandwidth to try and break what you had fixed and look for other issues. I saw your closing post on githib on this (I think it was only open for a day lol) and was surprised folks dont give feedback on these issues - it’s really an investment and in the best interest of everyone to strengthen the platform.
Yeah I get frustrated sometimes with feedback but, I’m learning the open source world is just a different environment than i’m used to working in. I get it though, sometimes folks are just as busy as I am.
I’ve been putting in the hours because I need to get patch 4 out and 502 as stable as I can so I can get back to v6 development and MU. However, it needs to be right so, maybe we can get a solution for this issue.
As folks soon learn with OpenEMR, billing is just that, billing, with very little accounting. We reconcile somewhat but could be improved. I think our reports are pretty good however, it’s when report show a problem, fixing it can be difficult.
Maybe what we need is a hold for resolution status for claims needing to be resubmitted or handled in a different way. Or just honor the follow up flag as just that, needing follow up.
This i’ll explore but, we have to remember, anything I do concerning work flow in one area of claim adjustments affect billing in many other places. I guess that’s what the engineer is for right?
If anybody sees i’m wondering into foolishness, let me know…
thanks
Okay, for all that are keeping up with this.
Some notes and actions i’m taking:
I hope this is workable where there is more to be done in billing but, for now, I want to move on and will do more in patch 5.
I found by just marking out this clause in sl_eob_invoice I fixed what sounds like your issue.
// Check if save is clicked with nothing to post.
// if (allempty && delcount === 0) {
// alert(<?php echo xlj('Nothing to Post! Please review entries or use Cancel to exit //transaction')?>);
// return false;
I have been getting a periodic error when you manually click the button to send a secondary billing, instead of having medicare bill it internally, where it will mark the primary payment date as being like 100 years ago causing it to get thrown out for correction by in my case OfficeAlly.
Yep, that’d do it but I think i’ll make it more purposeful and add an Update button so we’ll still have that validation on normal workflow
thanks
@cverk From where are you doing this?
If you click the button on invoice actions that says needs secondary billing and then send an x12 file from billing to the clearing house you have to correct the bottom part below the hcfa1500 form where the primary payment is shown for the secondary payor. I don’t recall exactly but it gives a date of like 1900.
It doesn’t come up very often because most medicare secondary plans get billed automatically by medicare and it really only happens in medicare claims because only they have secondary plans that need to be billed.
I’ll look to see if I can spot where the date gets set.
Hi,
@cverk
I think I found the reason this is intermittent. Prob happens on claims you’ve reset Done with(last level closed).
Turns out it’s the reason the no changes to form validation is in place. If user submits a save without changes, then a new ar_session is created w/o any session activity entries. Moreover, this new session is not populated with current session claim status i.e empty dates etc.
At least I believe this is your(and others) case. Still, we don’t want so, I created a new button where user can save just the Done with status to avoid this chance and dirty database.
I agree with this and it isn’t the same as accounting per se but there is an accounting/business management component to consider since this is solely relied upon for keeping accounts and payments straight. It does carry the same importance as an accounts receivables register but absent of all the tax implications. Lord knows insurances won’t jump to make a payment on a claim if left unchecked and a patient who gets a bill for more than they expected will let you know as well =)
I would agree this makes the most sense to leave in this invoice screen that reflects the payment/non payment activity. It would make for a difficult user experience otherwise to hunt down what’s going on.
This was how I had updated as well - until I tested this patch I was not able to absent of the zero dollar entry error.
Side Q: In the patch you updated there is a field for “Distributed to Global” what is this Global you speak of and how does this work? I came across an error a while back regarding to a global account but I could not find any data about it in the wiki’s/etc.
No matter, this method proves troublesome as a new empty AR session will get created where i’m still trying to figure out how this could affect future claim actions. Currently, I believe it gets ignored and just clutters the ar session table. Still, i’ve added a button for user to update insurance close level hoping to put this to bed for awhile.
Yes, this once hidden amount is/was befuddling to me too.
The intentions(i’m guessing and not speaking for original author) is to allow charging off undistributed funds(to balance all charges against payment where payment can’t be allocated otherwise against a patient charge via individual charge adjustments etc) to a global account. This account is only global to the payment however and not a running total. Out of sight, out of mind so to say. User will get this option to store balances in global account if user finishes payments allocations and there is still a balance against payment.
I’m supposing intentions where to reconcile this account at some future point in development but, I can’t find that was ever done. So, I thought billers would want to know about this fund and/or return funds back to payment to be debited against if accidental population or a woops, a patient charge was changed between billing and posting. Bottom line, I thought biller should have options to view and/or recover this fund.
hmm, looks like I need to restyle that form field and give a little more space…
Hope to have a testing patch today.
@jjalb and all interested,
Here is my final before we release patch 4: final_502_prepatch_4.zip - Google Drive
This patch will be same as released patch 4 so, ya shouldn’t have to install it. Review released though.
New in this patch for batch payments:
@nursejeff @ @PeggyG
Concerning the original issues of this thread, I was hoping that the bugs I identified and fixed would help your situation.
The main bug I found in batch payments affecting 502 and not 501 was a major bug. Understandably would explain the issues you were having and more. I would also expect residual issues from prior compounding errors after the patch however, if you’re still having issues then I want to help if I can.
My problem with any billing issues are many but mainly, i’m not that versed with the art of billing(I have new found respect for billers. ) and many times, difficult for me to recreate the issues. If I can narrow down to an issue, then I can fix it and happy to.
If you still have issues(looks like you may) please reiterate for me trying to be as specific as you can with the workflow that led to issues and as detailed as possible how I may be able to recreate.
It bothers me that such a long time and loyal user of OpenEMR is having these difficulties! While patch 4 may go out w/o a resolution for your issue, there’s nothing stopping me from doing a prepatch to patch 5.
Thanks Jerry! I hope to have it uploaded and test it through in the next few days once it’s uploaded to test.
@juggernautsei - Sherwin can you upload this to the test server please?
