We’re having a problem with the Save and Close button on the Fee Sheet. It is not intuitive to our providers whether they should click the Save button or the Save and Close button when they are done entering their billing information on the fee sheet. Consequently, they often choose the Save and Close button, which means we don’t get paid for the encounter. :-/ Of course, I’ll educate the providers, but is it really necessary to have a Save and Close button? Could we add a global setting to deactivate this button for the probably (?) majority of medical practices for which this button would be detrimental?
I still send paper claims to Medicare via our old practice management software. The dot matrix printer does a better job with alignment of the text. It is also less expensive to send the paper claims than to use the clearinghouse.
After entering Medicare charges from the Fee Sheet, I would go to the Billing module and use the Mark As Cleared button to prevent these Medicare charges from going to the clearinghouse. Now I can just use Save and Close directly from the Fee Sheet.
Nice feature, in theory. Using 4.1.1(13) just now, as soon as charges were added the button disappeared. Because the button is ephemeral, I was unaware of it.
The button does not work to clear an encounter that has no charges, i.e., a No Show, from the Billing module. That can be accomplished only by going directly into the Encounter module and deleting it.
Dr. Lee,
I am curious about your workflow. Do you enter Medicare charges in both OpenEMR and your old PM software? What would you need improved in OpenEMR such that you would prefer it over your old PM? Unfortunately I don’t think we can support dot matrix printing in OpenEMR though. My current machine doesn’t have a parallel port Sometimes the old ways are the best ways.
This idiosyncractic way of charge entry is the result of the fact that Office Ally has a surcharge, if more than 50% of the claims are governmental, Medicare & Medicaid, (now it is free); that there is an overabundance of CMS 1500 forms in the office; that the cartridges for the dot matrix printer are far less expensive than that for the inkjet printer and that frugality is a god in the office. It is no reflection on OpenEMR.
For printers with just one type of ports; adapters, which are fairly inexpensive, will bridge the difference. Our dot matrix printer has both a parallel port and an USB port, but the latter did not work with OpenEMR.
The old practice management software will not support ICD-10 codes, so I may be forced in 2014 to enter charges efficiently and rationally using just OpenEMR. If I can finagle the digital Medicare form in accepting the ICD-10 codes, the eccentricity may continue.
What I don’t understand is how Dr. Kay’s office have their Fee Sheets Marked as Cleared by clicking the Save and Close button if the Fee Sheets have charges on them. As I found out today, once charges are entered in the Fee Sheet, the Save and Close button vanishes. It makes sense to have it programmed this way, because one would not want to prevent charges from reaching the payors/clearinghouse, except in my rather unusual circumstance with Medicare billing.
Using 4.1.1 (12) & (13) with Windows 7, the Save and Close button disappeared with charge entry. This was the case with 4.1.0. as well. Unable to explain this behavior.
The Demo was in Dutch yesterday, rendering it inaccessible.
Today using the Demo, which is (13)(?),:
Charge entry did not eliminated the Save and Close button.
Clicking the Save and Close button on a Fee Sheet with charges, did not mark it as cleared. It merely saved it because it appeared in Billing as it should.
Clicking the buttton on a Fee Sheet without charges, deleted it but not the encounter.
So, Devi is right after all. If the button is disabled per Devi’s instructions, perhaps it would solve the problem.
what do you mean by THE DEMO WAS IN DUTCH, RENDERING IT INACCESSIBLE?
Double-Dutch or Dutch-treat? I only added translations in the Google spreadsheet during the last week and who else is accustomed to work with anything in Dutch for OpenEMR? Or did anybody change the password for the Administrator… and this was reset in the morning…
Please, if somebody else is working with Dutch, please give me your name so we can join power to overcome some problems for Dutch settings.
The regular Demo was in Dutch and Spanish (Spain) yesterday about noon in your time zone with no other options in the drop down menu. Because I can’t read Dutch/Spanish, I did not use it. Periodically the Demo is available only in a non-English version. Once it was all in Turkish.
I doubt that the strange behavior of the Demo has any bearing on your translation work. Perhaps El Jefe can figure it out.
This has to do with someone doing the following exercise:
Administration => Globals => Disable or Enable All Languages => choose Dutch and Spanish… or do a blind and allow All Languages… logout and login again. Or wait till next reset is done around 11:00 hrs Eastern Standard Time every morning.
To correct this in an unknown language you have to follow these steps in the blind.
Even with non-Roman scripts, it is not that hard to change the default back to English. I had a quick look at traditional Chinese, Greek, Turkish and Vietnamese. Nice that the login remains the same. So won’t have to wait for reset.
Atlantic Standard Time = Eastern Daylight Saving Time.
If you want to “train” yourself to use the demo even when the language setting has been changed, then set it to the “dummy” language only in the Development version and try to login and fix it. Once you can do this, then you will never be bothered by such issues. A couple months ago, the development demo was set to the dummy language; made me chuckle.
Do note the main official demo sees 100+ users daily, thus it can get pretty messed up rather quickly.
My biller says that when our staff clicks the Save and Close button, a claim gets generated, but it doesn’t get included in the electronic claim file we upload to the clearinghouse, so it doesn’t get billed.
All the claims are in the Billing Manager and have been selected. See first attachment. The Generate X12 button has been clicked, the text file has been downloaded and all the claims are in the X12. See second attachment. A quicker way to check that all the claims have been included is to look at the Error Log (click View Log). All the patients’ names and encounters should be there.
If the biller knows the location of the X12 file; while at the clearinghouse website, she browses to that file and clicks the Upload button; what is preventing the upload of the X12 file?
Was the upload of the X12 files successfully in the past? If so, what are you doing differently now?
If you use Office Ally, an entire batch can be rejected if a few in the batch have errors not specified in the Error Log. Are you getting batch rejections? Office Ally Support is usually able to isolate the claims which are causing the problems and to give instructions to fix the X12 file.
Sometimes the old ways are the best ways.