We just had a circumstance for which the drop-down list in the EOB processing is not adequate. Medicare paid us a late payment fee, required by law in NYS. As well, we often have patients for whom we bill repeatedly before we get the copay, which we cannot always know (things like annual deductibles are split among first billers in a given year). But if we simply enter the paid amount, it screws up the math and reduces the actual Pt Resp amounts we bill.
By adding "Late Pay Fee" and "Other Earned" to the dropdown array from line 44 (by the way, changing that to the "text w/ add" function, as with all dropdowns in OpenEMR, might be nice) we can handle interest charges on unpaid balances each month by entering a MINUS value in the "W" box and then selecting one of those. Those types of charges are perfectly correct despite exceeding the "allowed" Medicare amounts. Charging 1.5% of the balance over 30 days, so long as it is stated in patient agreements, is simply accomplished this way.
The minus value will effectively increase the "Balance" shown which is billed to the next payer (and ultimately patient).
I find no other way to handle this issue. Any ideas?
hey,
Rod migrated this list to the ‘lists’ in current cvs. I noted a bug when modifying this list in the cvs version. When saving it, it errors out becuase of ’ character in ‘To ded’ble’. After error, ‘To ded’ble’ is changed forever to ‘To dedble’. I don’t know enough about billing, but I assume this change in the string may cause issues with logic. My time’s a bit limited, so can’t fix this bug; placed bug in tracker: https://sourceforge.net/tracker/?func=detail&aid=2807026&group_id=60081&atid=493001
-brady
Turning magic_quotes_gpc on fixes it (my development box has this turned off), but aren’t we trying to get away from this setting at some point since it won’t be supported in php6. I’ll downgrade the priority of this bug in tracker.
Yes, OpenEMR should work equally well with or without magic_quotes_gpc. I’d suggest making the bug description more general, to include all code that does not yet do this.
hey,
This is the only place I know of (CAMOS was an offender, but I’m pretty sure Mark has fixed it) that I’ve had issues with magic_quotes_gpc in cvs code. Let me know of other offenders in openemr and I’ll then broaden the bug with this info. I’d suggest developers turn magic_quotes_gpc off in their environments to catch this stuff. ( Of course, still rec. keeping magic_quotes_gpc on in production environments).
-brady
The address book also has an issue with magic quotes. I tested by typing in a organization name with a single quote (i.e. Mike’s Medical Supplies). After submitting to the db, all that is displayed is “Mike.”
I think the question is not which code is offending, but which code is not offending. Seems to me that proper handling of form data requires using get_magic_quotes_gpc() to see if addslashes() or whatever is appropriate. However I don’t see that being done very much.
Curiously, the address book of all places should not be having a problem with it. See the function invalue() in interface/usergroup/addrbook_edit.php. Must be a slip-up there somewhere.
I have wondered since i first saw it what that "magic_quotes_gpc" was all about, since its descriptive comments could best be described as "brief". And I recall at the initial implementation of 3.0 the forums reversed themselves twice on whether that should be On or Off. I will change my users to "On" again. I think we are not likely to need PHP 6 in the next few releases, since the last i saw we were still trying to assure PHP 4 compatibility, right?
At least I now know. With the conversion in CVS to a List type, will it have the "text box w/ add" functionality?