whimmel wrote on Wednesday, September 02, 2009:
(Rod?)
I’m looking to add the Allowed Amount as a column to the EOB Posting Search between Charge and Adjust. I’ve traced through parse_era and the era_callback() in sl_eob_process.php and I see how the Allowed Amount is output on the report but doesn’t appear to be stored anywhere.
It doesn’t seem appropriate to add this to ar_activity… maybe billing or form_encounter. Does anyone have a recommendation (or maybe I missed something)?
sunsetsystems wrote on Wednesday, September 02, 2009:
Well it’s always a pain for me to dig into the ERA logic, so I’ll try to answer without doing that.
As I recall ERA processing does save all adjustments in ar_activity. However some of these are stored as “comments”, meaning with a zero adjustment amount (the amount is saved in the text of the comment), because they simply shift burden of payment from the insurance company to the patient and are thus not an adjustment to the invoice amount due. I don’t recall offhand if Allowed Amount is in that category.
Hope that helps.
whimmel wrote on Wednesday, September 02, 2009:
Ok, that makes sense and I was able to find in era_callback() where this would take place. There is a section around line 280 that checks if $svc[‘allowed’] and then does some stuff but doesn’t store this value anywhere.
I can see how to add it to the memo line by calling arPostPayment() but now I’m wondering if the memo column should be split into two.
I’d leave memo alone so it can continue to be used as it is, but then also add a memo_type column that is a FK to list_options and a default value of null. This would let us join against the memo column for certain things… like in my case, the allowed amount. (e.g. where memo_type = ‘allowed’). Right now it’s hard to pick out useful values from the memo column.
Upon further enhancements, we’d be able to join the adjustment code against another list so that we could have more meaningful descriptions on the statements sent to patients and those displayed on the EOB invoice itself instead of “Adj code 45”.
What do you think?
sunsetsystems wrote on Wednesday, September 02, 2009:
Checking the code you refer to, I’m pretty sure it does store the allowed amount value if it is not already there. It’s written to an array whose entries are later written to the database. Check your ar_activity table and these comments from the above-mentioned code:
// A problem here is that some payers will include an adjustment
// reflecting the allowed amount, others not. So here we need to
// check if the adjustment exists, and if not then create it. We
// assume that any nonzero CO (Contractual Obligation) or PI
// (Payer Initiated) adjustment is good enough.
Certainly ar_activity could be enhanced in some way to make it easier to follow what the payer’s “reasoning” is. Maybe even a separate money column for “contractual obligation” type adjustments (those that do not affect the invoice balance). But at the end of the day, “allowed amount” just reflects what was paid. Does it really matter?
Re "Adj code 45", yes those can certainly be expanded and there is a suitable hard-coded list already. See interface/billing/adjust_reason_codes.php.
whimmel wrote on Wednesday, September 02, 2009:
What we are trying to figure out are those situations where the amount paid does not add up to the allowed amount.
sunsetsystems wrote on Wednesday, September 02, 2009:
As the code comments imply, often they do not add up – and part of what ERA processing does is try to fix things like that. In my experience, for many payers the quality of ERA data is very poor.
By the way preg_match() is very handy for extracting data from text.
whimmel wrote on Thursday, September 03, 2009:
> As the code comments imply, often they do not add up – and part of what ERA processing
> does is try to fix things like that. In my experience, for many payers the quality of ERA data is
> very poor.
yes, but in the situations where the ERA processing is unable to fix it there isn’t a report or an obvious (to the user) reason why. It just leaves an invoice with a balance due from the patient. (That’s another thing… we’re finding that it doesn’t automatically become due from the secondary payer when the pt has an active secondary insurance)
I’m trying to automate this analysis for our client’s billers. It’s cumbersome to do this research manually for so many entries.
> By the way preg_match() is very handy for extracting data from text.
Thanks for that.
sunsetsystems wrote on Thursday, September 03, 2009:
Bill, your efforts to improve this area are most welcomed.