This is to mention that I checked in a couple of new modules for entering and reporting on payments received by the front office, and for printing associated receipts. Mostly these payments are copays, but some will be from patients who walk in to pay part or all of a prior balance.
An obvious improvement would be to automate the posting of these amounts into encounters or into AR, as appropriate. My client has not yet requested that, but might do so.
Rod
Where on OEMR would I locate these changes? I’ve looked on the main navigation bar and I’ve also pulled up a patient record and looked on that navigation bar.
Thanks
Alfonso
Nope, Not there. No ‘Payments’ in the Popups thingy at the tip right of the screen. Which of the files creates the Popups thingy? This way I can check if I´m missing or got the wrong one. Whats interesting is I’ve got these two files in there, interface/reports/front_receipts_report.php
interface/patient_file/front_payment.php
Nothing yet. It’s still just a standalone tool for collecting and reporting on payments. It would be good to enhance it to post to the billing table (for copays) or to A/R (for previously billed encounters).
Note that in the case of a copay prior to the corresponding encounter being created, we would want the posting to happen later when the encounter is created.
I am using a system now which is incredibly successful for us for recording payments. I am not using sql-ledger at all.
I record all payments as copayments by clicking the copayment link at the lower left in the encounter screen.
With some modifications, which should be available in cvs, I can record if the payment is credit card, cash, check, etc…
This is documented in the lower left frame and there is a receipt link for a printable receipt.
It keeps payments associated with encounters and it makes it easy to accept payments of multiple forms which will reflect appropriately on the receipt (e.g. $50 cash, $50 credit). We can also go into a previous encounter and apply a payment.
I also use a modified version of the billing report page (which I have not yet submitted to cvs) which gives me a running, color-coded, report of charges and payments and an overall report at the bottom.
Modifications to the front desk payment and receipt files and the copay files could be made to merge functionality.
For our office, which is currently mostly self-pay, it is working very well.
Yes, changes to copay.php and diagnosis.php recently committed by Andres for me.
billing_report.php has the color-coded reporting modifications which I need to make available as an alternate, because the changes will confuse those who do not record payments as copays (in the billing table).
A question, not having actually tested it yet, once the payment is created, if one clicks on the copay link, will the payment "automatically" appear in to copay section, or does one need to re-enter the amount in the copay?
My wife started her staff using the payment popup, but stopped shortly thereafter because the payment wasn’t showing up anywhere. Perhaps I need to get a fresher copy (mine is from cvs as of last weekend Mar. 25, 2006).
copays are inserted into the billing table by a line of code near the top of diagnosis.php.
front_payment.php inserts into the payments table.
If the two places were made to cross insert into each appropriate table, it would solve most confusion and problems, giving users two places to enter payments/copayments.
I think this is essentially what Rod said a few posts back in this thread.
OK. So, what do we do from here. I think it would make sense to do as you suggested, namely use both tables payments and the billing table to record the money received. If a payment record is created it should be applied to a bill/encounter evenutally (when this occurs will be different pending the timing of the payment received and the encounter). I guess, even thinking about it, there should be the one interface for payments and that takes care of everything (copay or other payment received). If the copayment link is pressed it should bring up the payment entry screen, yes? There could be a parameter to the front_payment.php that takes the encounter, if there is one, and apply the payment as a copay to that encounter. If the encounter is null then just add the payment record to the table. Now how to link/apply payments to encounters for encounters created after the payment is received… hmmmm. Again, once the copay link is clicked invoking the payment form the payment form should list all payments for the patient received that aren’t linked to a bill/encounter. Clicking on the payment record would create an entry in the bill/encounter. What about multiple payment entries? Does the current billing interface account for multiple entries? Not sure…
Anyway those are my thoughts, what do you guys think?
The payments table contains "amount1" and "amount2" which are for the current visit and for a past balance, respectively. There are corresponding fields "posted1" and "posted2", currently unused but intended to record the amounts posted to the billing table (for a copay) or to SQL-Ledger (for a past balance).
So I think the thing to do from here is:
(1) Modify the code that creates a new encounter to check the payments table for a positive value for (amount1 - posted1) on that same day for that patient, and if found then put that amount in the billing table as a copay and also add it to posted1; and
(2) Enhance something, perhaps front_payment.php itself, to post any amount2 to SQL-Ledger in a similar way.
Yes, I guess it’s probably OK to have multiple copays for the same encounter but do not recall testing that.
Currently, the only way something get to SQL-Ledger is through the billing screen, right, using "clear" or "generate electronic batch and clear". I think it would be best to keep it that way to keep is simple (only one interface to worry about). All payments would go to the billing screen by linking them to an encounter. I think that makes sense unless there are other reasons a patient would give money to the doctor.
Also, adding an encounter field to the payments table to link it against the billing table would be useful.
The EOB code also posts payments to SQL-Ledger. It would be reasonable to factor out an includable module to make it easier for other parts of OpenEMR to do that also.
Understand that the "front office payments" code was created mainly so that payments received at the front desk can be easily tallied up and accounted for at the end of the day, or at the end of a shift. Anyone who runs a retail business understands the importance of this.
Having said all this, it’s not really necessary for this code to post to SQL-Ledger amounts paid on encounters that were already billed – the back office can certainly re-enter those manually and they will not be frequent; it’s just a useful level of automation.
Agreed that a link from payments to encounters may be useful, though there would rarely be any ambiguity in the case of copays since the dates will match.