We have been contracted to add a much needed feature into OpenEMR dealing with Editing/Deleting already posted EOB transactions. Just want to make sure we covered all bases because it was a relational reference that referenced a couple tables.
So far we noticed that EOB Posting Transactions reflect the following tables: “ar_activity” and “ar_sessions”
Can anyone think of any other tables that are touched when dealing with accounts receivables? Any suggestions? Right now we just created a new column heading called “Action” then underneath for each transaction we have a button for “Edit” and “Delete”. If you select edit it pops up another window in which you can edit the transaction. If you select “Delete” it will have a popup to confirm your decision.
We will make a diff and upload to tip once completed since this should be an included feature.
I have two other requests for similar features. No coding has started. However i think that this is a first step only. The EOB posting process should be designed to be a batch process. That is, the user posts a EOB batch (from an InsCo or pile of check for the day) and is then given a chance to review, correct and balance the information before it’s posted to the patients records. Alternatively you could allow the EOB batch as a whole to be recalled for edit but create a process that allows it to be locked after a certain number of days or by the ‘accounting department’ at month - end.
-Tony
Thanks for the input. Coding is actually almost completed. Should be done in several more hours. I will post a demo. A guess a quick way to do this is to warn that editing posted transactions after secondary billing has been sent out shouldn’t be done. Or locking the transaction if secondary billing has been created… not sure the best way to handle this.
The original request was just to delete transactions, but figured since we were in there it would be nice to edit the transaction for those 1 off errors! You know when you hit save and then slam your forehead because of a clerical error… which is what this is really suppose to be used for. Not for errors you find a month later.
My developer working on this project noticed that there is a time stamp associated with the transactions. So, he’s going to make it so that you can only edit/delete a posting within a 24 hour time frame of it being posted. Does that sound like a viable solution?
The one issue with EOB if someone posts an entry wrongly and clicks the enter button without hitting save the entry gets saved. Is there anyway to correct the data entry error. For instance instead of 43.47 someone typed it as 34.37 andpressed the enter button. We need to have the ability to correct such errors. Any help woyld be appreciated.
I agree with Tony. I was also trying to begin work on this module. I would say that for all financila transactions we should have a lock that could be decided by the accounting department, as we see in accounting software like QuickBooks. A 24 hour lock may not be enough: it should be manually locked.
The following should be noted:
Editing should be for the entire EOB/check no.
Once the EOB is posted the corresponding claims cannot be reopened, whether it be primary, secondary or tertiary.
Even for the EOB posting I was wondering if we should validate whether the entire amount has been distributed before saving it.
Thanks
Sam
Raj, that’s exactly what this fix is for… but you can only correct your fix within 24 hours.
zhhealthcare, the issue with a manual lock is that when dealing with billing, especially billing companies… this extra account maintenance would add atleast 20 seconds to each posting/claim. Doesn’t seem like much but times that by 100’s of claims per day and we are talking about a lot more clicks!
Chris
I did not explain clearly. What I meant was to have a master-file in the Practice level where you enter the closing date. The way QuickBooks does is to have it in the Company Preferences. Which means you can post edit delete transactions all you want, but once the chief accountant reviews everything and goes in the master file and locks it to a certain date, then it’s done. So essentially it is a date field to be added at the practice level. And whenever someone wants to edit something the program checks with the masterfile to see if the date is greater than the masterfile date and allows it, if it is less then disallow it.
This already exists. In the main Billing section, you can mark an encounter as closed, meaning no more billing can be done to the encounter… it will be locked. Just click on “Mark as Clear” with the encounter selected in order to do this.
Hi Chris,
the problem with “Mark as Clear” is you can click that as many times as you wnat and it make a note of it in patients record in billing. I think I would use zero balance in EOB to set the “Mark as Clear”.The way it is set up today , you rely on billing person to balance checks and payments to clear off payments(Mark as Clear)…not very effective and basically opening door to more errors.
That was my point too. Marked as clear doesn’t validate anything. If an EOB is posted then we SHOULD NOT be able to reopen it unless the EOB is deleted .
Also I was talking about dates to lock the editing of the EOB, not the claims.
I’m not sure it’s right to support editing or deleting of transactions. Why is that a “much needed feature”? It’s important to maintain a history of what happened, even when an entry was in error. You can enter additional adjustment transactions to serve as corrections.
Bigger practices have different employees to enter billing data, and they do make mistakes. So it is absolutely essential to have the option to edit or delete such entries after review by the supervisor. Once it is reviewed and locked by the supervisor then no edit/delete will take place. Any transactions after that will be adjustment entries.
Also, a big headache is when someone forgot to enter a deposit date. When you go to bill for secondary billing the claim will get rejected because there’s no deposit date. The only way I figured to edit the deposit date is by going directly into the database and inputting a deposit date.
Just saying, adjustment entries can be used to correct mistakes. I have never liked writing code to delete stuff in a medical or financial application. If you must do it then make sure it’s restricted to those with admin/super rights by default, as are most other deletes.
Not sure I understand why a secondary payer cares about deposit dates, but that sounds like another discussion.
This is why I propose a batch process. So that the data IS not committed to the accounting records until it has been reviewed and approved. This is a very standard accounting practice. Adjustments are the appropriate way to change $ amount after words, but not having a way to review and correct data entry errors early in the process is not efficient. The person who is posting the info should be able to correct their own work prior to “approving” the WHOLE batch for posting. After that adjustments for the accounting role and admin only edits for anything else (with logging).
The ar_session table may be of interest to this discussion. It was so named in anticipation of supporting “posting sessions”, each of which corresponds to a check from a payer that covers multiple claims. The total check amount would be balanced against the total of the entries for the associated claims. Also anticipated was the ability to interrupt a posting session and resume it later. Note this table also has a “closed” flag.
Consideration should also be made to display the person or username or ID of the person who has posted the payments or made adjustments. Right now it is difficult to determine who has done what in the billing sections. In addition, when you look at the current posting reports there is no way to pull a total based on insurance dollars posted.
I appreciate. As long as there is a way to correct data entry mistake it will be fine. I appreciate the clarification. If my understanding is correct now the correction has to be made only at the Data base level !!! Am I right?
While on this subject another feature would be the ability to post one single check against several claims on one sheet. Always the insurance companies send on check against several claims. Presently my understanding is that the posting done on a patient by patient basis.