Persistent Error Logs In Billing Module

Day-to-Day Users
1

fsgl wrote on Tuesday, December 30, 2014:

In 4.2.0 it appears that we have a bug in the View Log of the Billing Module, which was confirmed in the 4.2.0 Demo.

After errors have been corrected, the Log continues to display the errors. I purposely did not correct errors, all at once, to demonstrate the bug. The second log contained the errors of the first log, while the third log contained the errors from the 2 prior logs. See attachment.

In 4.1.2 (7) all errors disappeared after the correction had been completed.

This is not a show stopper because it does not interfere with claim submission. The user should be aware until the bug has been fixed.

2

bradymiller wrote on Wednesday, December 31, 2014:

Hi,

As I recall, this was done purposefully(appended to file rather than overwriting it in order to keep a record of the logs):
https://sourceforge.net/p/openemr/discussion/202506/thread/8ba5a98e/

-brady
OpenEMR

3

fsgl wrote on Wednesday, December 31, 2014:

Thanks for the link.

We have only 1 office, so enhancement for multi-sites not needed.

Will use this to revert.

4

fsgl wrote on Wednesday, December 31, 2014:

It is not as easy as one had hoped.

  1. billing_process.php line 122 replaced with old snippet, line 125 deleted.
  2. billing_report.php line 468 replaced with old snippet, line 469 deleted.

The result was that the “View Log” button went AWOL. A blank space in its place.

Deleting/retaining customize_log.php had no effect on the missing button.

No error messages popped up. Did not review error logs.

Backup worked upon recovery (Thanks, CVerk).

Workaround: copy/paste the desired part of the View Log to Notepad for printing.

5

fsgl wrote on Thursday, January 01, 2015:

Fixed.

  1. billing_process.php line 122 replaced with old snippet, line 125 retained.
  2. billing_report.php line 468 replaced with old snippet, line 469 retained.
  3. customize_log.php retained.

Essentially, restore the pink in first two scripts as illustrated here.

6

bradymiller wrote on Thursday, January 01, 2015:

Hi,

Try this.

Change this line:

To:

$hlog = fopen($GLOBALS['OE_SITE_DIR']. "/edi/process_bills.log", 'w');

(note the ‘a’ was changed to ‘w’)

Is it better to have it append the file(thus saving old log entries) or overwrite the file. Or should this be an option in globals?

-brady
OpenEMR

7

fsgl wrote on Thursday, January 01, 2015:

If I had to guess, most users are in a single office practice; therefore the multi-site enhancement is not applicable to the majority of users.

I don’t save the View Logs with errors. Once I am aware of the errors, they are corrected. The post-correction log is printed as a record of submitted claims.

It is helpful to know when a claim has been sent, to facilitate tracking, should there be a need for resubmission. On the same sheet is written the File ID from Office Ally & the Batch Number generated by the Billing Manager, in event of a problem with the 837P.

Adding this feature as a Globals option should make most of us happy. Beginner users are very likely to be squeamish about wading into the weeds to change codes. I would defer to your judgment how best to code the option.

8

bradymiller wrote on Sunday, January 04, 2015:

Hi,

Migrating logs outside the “read-only” part of the codebase is not just for multi-site; also eases the installation process and clarifies the codebase more for the developers (then only need to ensure stuff in sites/*/documents etc. is writable).

Two options are:

  1. Place option in the Administration->Globals->Logging->‘Billing Log’ to allow ‘Billing Log Overwrite’ or ‘Billing Log Amend’ (this is the easy way, which I can likely do at some point or would be a very easy project for a new developer)
  2. Make a sql table billing_log(id,timestamp,data) and place each entry in it rather than copy it to a file. Then on the report would have bunch of options (choosing dates, sorting, etc.).(this is the harder way, which somebody with more time will need to do; and if it would even be useful)

-brady
OpenEMR

9

fsgl wrote on Sunday, January 04, 2015:

My vote is for first option.

What we have now:

  1. batch number which doubles as the timestamp, in hour:minute, 24 hour format.
  2. fairly easy sorting with different filters, once claims have been processed as 837P/paper.

(Besides, the ball point pen is still a good friend.)

Thank you.

10

bradymiller wrote on Sunday, January 04, 2015:

Hi,

Just committed this option (first option) to the codebase. Will include this fix in the next 4.2.0 patch.

-brady
OpenEMR

11

kodusote wrote on Saturday, January 31, 2015:

I have a different error with the Billing Module log file. We have been using the Charge Panel for billing to patients. Now we need to send bills to third party payer (insurance or employer) and have not been able to generate any bill using the Billing Module. The apache error log shows that there is no permission to write the log file on line 122 of the billing_process.php file (see attached).

Can anyone advise on what could be causing this error and how to fix it?

Thanks.

Kayode

12

fsgl wrote on Saturday, January 31, 2015:

Hi Kayode,

To get things rolling, try this & let us know what happened.

That said, Charges Panel was built for self pay patients & not third party billing. I remember seeing a comment in the Wiki to avoid Charges Panel, relying on the Fee Sheet instead .

Charges Panel is a nifty little creature, I agree; but it’s not a super duper biller. I have a hunch that quite a bit of work will be required to stretch Charges Panel into the entity you wish it to be.