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
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.
1 Like
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: https://drive.google.com/file/d/1LqOAlM3d9ISt3UpVPwaovMNeMdv1ksjQ/view?usp=sharing
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:
- Honor the follow up flag when allocating for a denied payment.
This may be but one way to handle a denial. This method allows for creating a $0.00 payment then allocating the 0.00 to a patient charge with the follow up flag selected. If a reason is given, it will appear on the invoice as a payment note. This will cause the claims last level closed to remain the same and not advance billing to next insurance or the patient. Remember, Follow up flag and a 0.00 payment for allocated charge must be entered when allocating. This will be true for edited payment as well. The next item may be helpful in this case. - Added a new button/option in EOB Posting/invoice to reset current Done with/last level closed. Seems this is helpful to many.
2 Likes
@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.
1 Like
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?
@sjpadgett Ran through the test and it looks like everything is working now and not skipping the insurances if unpaid. Thanks so much Jerry!
Q: Is there a bug and/or suggestions thread anywhere to address issues that come up? I know some of this code has older origins and some of the thoughts behind fixes and changes have been lost over time. Some sort of thread like this might be helpful to existing as well as future users - I can only see the usage increase in the years to come. OpenEMR is too flexible to ignore.
I’ve also reviewed a demo of version 6.0 and it’s looking really good. Nice work!
1 Like
You’re welcome John! So glad we got to put to bed this issue that has troubled you for so long.
A note on billing: IMO and after looking over much of the billing code, the module was a difficult one to develop and was very well done however, over time billing practices change and we’ve fallen behind.
It is my hope for v6.0 we’ll do some major modifications. Starting with tying everything together in one place with some better general ledger capabilities and allow making corrections in a claim maintenance screen. Also a claims builder so we can consolidate several encounter claims into one claim etc. ie Billing Manager on steroids! Anyway, just some of my thoughts and any issues you come across the best thing from a developers point of view is by opening an issue where we can track. Here is link: Issues · openemr/openemr · GitHub this is what we pay closest attention.
Concerning v6.0; Thank you on behalf of all of us developers. The modernization team headed by @tywrenn and @stu01509 with admin oversight is working hard(I mean hard) to get OpenEMR onto the small device environment for most of our capabilities, I’m sure they’ll appreciate your notice. Also our API’s(standard and FHIR) will be of note in next version. This allows for mobile and other app development. I think several folks are developing as I write this.
Good luck and stay safe.
2 Likes
I have exact the same problem with secondary insurance payments posting, started from 5.0.1. Now after upgrading to 5.0.2(4), nothing changed. Before we had a problem only with old patients with more then 50 encounters, now after all upgrades we can’t post secondary insurance payments from Batch Payments.
@stephenwaite, We do not use ERA at all. We are still having a problem with the older Medicare 2ndary payments. If the EOB has several claims, sometimes 2 or 3 will not post. We are currently using Office Ally for medicare claims. Peggy
Hi Jerry
I have exact the same problem with secondary insurance payments posting, started from 5.0.1. Now after upgrading to 5.0.2(4), nothing changed. Before we had a problem only with old patients with more then 50 encounters, now after all upgrades we can’t post any secondary insurance payments from Batch Payments.
There is no any problem with primary insurance payments posting, only with secondary.
We did all recommended php settings, but no any changes in secondary posting
We using 5.0.2(4) with php7.2.
php7.2 settings updated to recommended
upload_max_filesize = 32M
post_max_size = 48M
memory_limit = 256M
max_execution_time = 60
max_input_vars = 3000
max_input_time = 1000
After php settings update no any changes, same problems.
Want to note I added an addendum patch for patch 5 that includes all by pre-patches i’ve released here and there for bug fixes.