Checkout issue

cverk wrote on Thursday, October 04, 2012:

Under the section for fees/checkout you are able to create what is the obvious choice for giving a patient a receipt at checkout.  In my office, the vast majority of those requests are for patients to have a record of copayments made usually for flebible benefit spending plans. Very few people pay the full balance before leaving the office, before insurance billing has been completed.  The default however when you create that receipt shows the patient paying the entire balance. If you notice that it can be removed, but it seems it shouldn’t be the default.  When you push the save button which is needed to allow printing, the program removes the claim from the billing manager, so it is not available for insurance billing.  You can prevent that by pushing the undo button after printing, but then any copayment that was paid by the patient is also removed from the claim. Luckily we track copays paid on our superbill and could go back and reenter them instead of thinking later that they hadn’t been paid, but again that should not be happening. It seems fixing these little issues would make this whole area much more useful in the real world of office practice.

hitechelp wrote on Thursday, October 04, 2012:

To further expand on that;

Getting “Checkout” to work well for you may be a simple procedural adaptation. 
This is what we came up with;  (We’re using v4.1.0 (11))

1.  Patient arrives > change calendar status > encounter auto generates
2.  Front office creates and saves fee sheet (CPT is known but, no diagnosis code from doctor yet)
3. Doc sees patient
4. Front office completes “Checkout” and changes calendar status to “Checked out”
5. Front office Re-Opens encounter.  (Fee sheet can now be completed)

Obviously, this won’t work for everyone. 
Since there are multiple ways of entering co-pays and receiving payments, one must understand how these different methods interact with administrative and financial procedures before setting said procedures in place. 
Without sufficient documentation you either hire someone or learn by trial and error as we did.

Multiple ways of doing a thing make a system adaptable but undocumented ways can create inconsistent results.

My two cents worth of POTO (pointing out the obvious) and some ideas are offered below;

We stopped using the “Add Copay” button on the Fee Sheet because it creates a negative value (an accounting black hole) instead of a payment that can be safeguarded with a daily accounting reconciliation as “Checkout” allows us to do. Its like having a cash register.  Payments received this way are not as likely to disappear, and receipt printing is easy.

“Payments” is the accountants way to accept money, but it’s time consuming and requires many steps to achieve nearly the same results as “Checkout”  (payments received using Checkout can not be searched like those in “Payments”)

Having the “Checkout” amount auto-fill from “CoPay” under “Insurance” would be more useful than the current scheme, as long as you can still modify it (needed for split payment purposes).  Any amount could be set and called from there. 

If “Checkout” could change a patient’s status in the calendar to “Checked Out” that would save a step.

And,  instead of showing “CO-PAY” as a minus (-$xx.xx) in the “Bal” column on the “Past Encounters” (billing view),
have it zero out when paid in full, (as it does when using “Payments”) which gives a nice clean appearance, no confusion.

And lastly, no apologies for all the different ways I’ve referred to  “Co-Pay” because each instance appears in quotes as it appears on the screen to which it refers. 

“COPAY” on the Fee Sheet, “CO-PAY” on Past Encounters,  “CoPay” on Insurance, “Copay” on Edit Payments (is that all?)

By the way, just in case you were wondering, I am not OCD - I’m CDO, which is OCD in alphabetic order ;o)

You Developers; Keep up the strong work,  We love OpenEMR!

cverk wrote on Sunday, October 07, 2012:

Still kind of confused by this, and the manual isn’t much help.  Should not the process work like this.  You create the encounter, code the visit, and use the add copay button if applicable, and save the encounter which places it in the cue to be billed to insurance.   If the patient wants a walkout receipt, you can select checkout, where the receipt should show any co-payment made, as well as details of the encounter coding.  Then only if payment makes the balance of the encounter zero, should the encounter be removed from the billing cue. Also, if a co-payment has been made by the patient, using the checkout function should not remove that payment. I have looked at the coding, but so far I have no real clue where you would start in correcting that.

bradymiller wrote on Monday, October 08, 2012:

Hi cverk,
Agreed. Note that the co-pay should up on the Check Out screen (this is something I remember doing when fixing some bugs after we migrated co-pays ar_activity/ar_session sql tables for 4.1.1) . To not set the billing flag unless the entire charge is paid off should be a really easy modification and I’m guessing would work as default flow for the general codebase. Just a matter of who has time to do it at this point(volunteer vs yourself vs pro).
-brady
OpenEMR

cverk wrote on Thursday, December 20, 2012:

Since my previous observation on social security numbers seems to have gotten some traction today, I thought I would tickle this thread and see if this was a problem to anyone else.

yehster wrote on Thursday, December 20, 2012:

Honestly, it’s Tony’s promise of cash for fixing the issue that provided the traction on the SS# issue.