drbowen wrote on Wednesday, June 15, 2005:
1)Track our AR
2)Transfer billing information directly from OpenEMR
3)Allow entering data from the EOB’s.
These questions are intimately tied up in the problem of AR management in a medical practice. They actually quite complex. Clearly Ezybiz is no where close to being adequate. SQL-Ledger does what it was intended to do quite well but it is not intended for AR management in a medical practice.
1)Errors in calculations. These should be easily repairable.
2)Difficulty of entering data: this is more complex, as the EOB’s could be entered but only one line item at a time, making the completion of an EOB a significant number of steps.
We enter EOB’s one line at a time. Insurance companies routinely lump multiple patient payments into one check with each CPT on a line. They also cheat you one line at a time by down coding, paying wrong amounts and lumping services together. I not sure if this will ever be solved in a practical fashion.
Due to these, we did not reach a point that we could successfully catch up our AR or produce a bill for our patients. At that point we contracted our billing to a company that we could export our data to, and they would manage our AR, and billing. To be fair, OpenEMR is not advertised with the functionality to track AR, and our inability to do so was due mostly to my inexperience.
It takes a couple of years of practice start learning the ins and outs of AR management. My best advice is to hire the most experienced medical billing clerk you can find (or as you did hire it out).
The limitations of OpenEMR are a bit more subtle. Some of them can be easily worked around. Some of these limitations are significant, and pervasive to the design of OpenEMR.
1)Open EMR has only two security settings, authorized, and unauthorized. Authorized users can do anything, and are listed on the calendar. They have the ability to access the practice settings, and database settings without limitations. Unauthorized users all have to have any action with the exception of appointments approved by an authorized users. These authorizations all appear in the bottom in the scheduling screen after logging in. These unfortunately are not just for the logged in provider, but lists all providers. The name of the provider is listed on my system, but I added that functionality and submitted it back to OpenEMR.org for addition into the source.
Clearly security with OpenEMR has been a big problem. We have recently implemented access control lists through phpGACL that give the administrator fine grained control over access. There is still some learning curve involved but this dramatically improves the ability to control security.
2)There is no way to currently track open encounters, or to finalize encoutners. This means that all encoutners are only accessible through the daily calendar. Billing is submitted as soon as it is entered, and if an encoutner is not completed, there is no reminder that it has not been finished.
This is a problem that has not been addressed.
3)OpenEMR is not thread safe. This is by far the most fatal flaw of OpenEMR. What this means is that when an patient account is open a browser window(1), if a new window(2) is opened, and you go to a different patient account, if you go back to the first window and save any data, it will be saved to the patient account or encounter open in window(2). This does not occur if you are on a different machine, or if you use a different browser. I have been told that this may be a limitation of PHP, but I have not verified that yet.
I think this occurs because of the nature of the web-based interaction between the browser, and the OpenEMR. As the browser opens a session it shares session information with the server. The browser stores information about the sessions as cookies. Netscape, Mozilla, and Firefox do not maintain separate cookies for each open window. As you open the second window the browser uses the last stored cookies. So when you go back to the first browser tab the browser still remembers the second window.
I have not tested this behavior extensively across different browsers but it seems to happen only in the tab style browsers such as Netscape, Mozilla, and Firefox. This is the reason that when you you do line banking you should explicitly open a new copy of the browser not just another tab. It allows a type of cross scripting attack from another open tab.
So I don’t think this is actually an OpenEMR bug but really a bug in Netscape, Mozilla and Firefox. We handle this here through behavioral modification. Many of our staff use MS Internet Explorer where the problem doesn’t exist. Most of the rest don’t know how to open a second tab. For the ones who do I simply explain the problem and it it solved by maintaining one open connection to the server with a single open window. Not an ideal solution but it works.
4)No Login tracking. If you do not log out at the end of a session, the session will time out, but the screen will not reload to the log in screen. Also, if you are entering a long note, and go beyond the time allotted for the session, it will expire, and will go to the log in screen when you submit the note. This results in the loss of the note.
Again, this a function of the stateless client-server architecture. There have been some ways proposed to solve this on the client side. Unfortunately it would likely require hacking a specific browser and then mandating this same browser which have not wanted to do.
Again I handle this through setting the time-out for as long as possible and then we do frequent saves during the visits to avoid the timeouts.
5)There is no easy way to set the billing date on submitted billable codes. For example, if you see a patient on Friday, but do not enter your billing till Monday, the billing will be submitted with the date of service of Monday. Also, if you add a form to an encoutner, then the date of the encoutner will be changed to the date the last addition to the chart was made.
This feature has already been added by Rod Roark.
Sam Bowen, MD
. Will be looking at your database table structure and deciding how complex it will be to maintain an interface to your system also.