Patient Ledger Inaccurate

Day-to-Day Users
,
41

@juggernautsei Yea, finally recreated in v5.0.0(3). Not sure I can explain it right now but it is most likely in deleter code.

Apparently the ar_session entry is overwritten. The amount and adjustment code are changed.

42

Okay have it figured out. To recreate do:

  1. Create some prepayments then encounter and fee sheet.
  2. Check ledger to ensure prepayments.
  3. Start a payment, select debit,cash,credit then Insurance radio and invoice balance.
  4. Add a payment in top box(todays encounter box) in the amount of one of your previous prepayments(must be same amount).
  5. Save.
  6. At receipt screen select delete because EU realized they werenā€™t suppose to do that way.
  7. Now check your ledger for the prepayment.

Now the previous prepayment in ar_session is a patient payment not associated with an encounter and thus will not show in ledger.

Hope I made this clear.

43

i believe @juggernautsei might say good show sir sherlock :slight_smile:

44

@stephenwaite
Does this make sense to you:
row_delete(
ā€œar_sessionā€,
ā€œpatient_id = 'ā€ . add_escape_custom($patient_id) . "ā€™ AND " .
"payer_id = 0 AND " .
ā€œreference = 'ā€ . add_escape_custom($payrow[ā€˜sourceā€™]) . "ā€™ AND " .
ā€œpay_total = 'ā€ . add_escape_custom($tpmt) . "ā€™ AND " .
"(SELECT COUNT(*) FROM ar_activity where ar_activity.session_id = ar_session.session_id) = 0 " .
ā€œORDER BY session_id DESC LIMIT 1ā€
);
where I believe should be:
row_delete( "ar_session", "patient_id = '" . add_escape_custom($patient_id) . "' AND " . "payer_id = 0 AND " . "reference = '" . add_escape_custom($payrow['source']) . "' AND " . "pay_total = '" . add_escape_custom($tpmt) . "' AND " . "(SELECT COUNT(*) FROM ar_activity where ar_activity.session_id = ar_session.session_id) " . "ORDER BY session_id DESC LIMIT 1" );
I donā€™t get the ā€™ = 0ā€™
This fixes btw

45

glad you found a fix, this looks like @sunsetsystems fix from openemr/deleter.php at d15518697b5578eecce93598d7764e7d4baae863 Ā· openemr/openemr Ā· GitHub

46

Yep been around for awhile. Think it was meant to be !=0 or =1 but the way it is written it will cause query to always eval to missing the session id in ar activity thus lookup results from just payment amount and pidā€¦whew, say that ten times:).
Started PR to address these issues. We can go there for further billing stuff.

1 Like
47

nice explanation, if only billing logic came naturally
ps pr will be handy

48

@juggernautsei I decided that iā€™m going to treat the Today encounter pay box for invoice balance the same as copay or self pay and ask to create encounter. I may go as far as putting a button in dialog to create a Today encounter and disable the box unless the payment has encounter. This way user decides and not application plus, cuts down on handling errors. This should alleviate part of the issues from wrong payment workflow recovery.
Do you see a problem with this? Also, I donā€™t understand why patient has to have appointment to create encounter, do you?

Also I could give you a simple patch that would allow showing all payments in ledger including patient payments that may have wrongly been accepted due to Today encounter zeroā€™ed invoice balance payments.They do not effect balances in ledger because they show as credit/debit neutral. May help hone in on billing errors.

1 Like
49

very nice @sjpadgett

itā€™d be pretty cool to distribute the invoice balance payments into payments against each line item/date of service

50

This is pretty $%^# cool. I am just now catching up with all the dialog. @sjpadgett great sleuthing and I can tell you had your hip waders on. The system does not require an appointment to open an encounter. Encounters can be manually opened. ( think you know that).

If you can provide a patch, that would most gracious of you and I can stop the cron job I am running now to move payments.

51

Okay, patch will include zeroed encounter fix for invoice balance, deleter query fix, allow all payments in ledger, fix for prepayments not summing correctly and maybe return from receipt dialog somewhere besides white screen. Will try to have for you by tonight or morning because by Friday, I fear I will need to upgrade to my chest waderā€™s. :slight_smile:

2 Likes
52

@juggernautsei @stephenwaite I put up on my git my fixes for the various issues discussed here. I will eventually do a PR so they get in Patch 4 along with some other enhancements Iā€™ll back port. I added payments session history in ledger so you can instantly see what the rest of billing sees. This may help somewhat with you wayward prepayments. Also, Some of the other back ports Iā€™ve done are scattered around this branch such as default rendering provider adjusted for PHP7.
Youā€™d be surprised to know that the form validation in front payment was broken and has been for some time. If it would have been working your problem may have never come up because it is designed to catch! Anyway iā€™m sure I am driving Mathew and Robert nuts with my long winded threads. Even the forum app complains at me. :wink:
I rec a little testing before implementing to be sure.

Front Payment and Patient Ledger issue fixes. Ā· openemr/openemr@b8c811f Ā· GitHub

2 Likes
53

I will implement these over the weekend so not to disrupt work flow and look for feedback on Monday end of the day. Thanks for being such a trooper!

54

@sjpadgett,

I have integrated the changes. I am going to leave the script running and recreate a log. I wonā€™t have it to write to the database. I will have the EU to report if there are missing payments to test the work you have so graciously done. I will report back in two weeks. That should be enough time.

55

UPDATE. It has been two weeks since I added the patch and there have been no payments found by my script that I had looking for lost payments. It looks fixed.

56

Iā€™d say good news. Hopefully others will see this thread that use prepayments and check their systems.