Looks like you have an onote thingy attached to that billing line (which shows up on the fee sheet since 4.1),
and you have either changed the fee sheet line items default (by code as I have) to “unauthorized”, or have unchecked the authorized box on that line item in the fee sheet.
Typically, our fee sheet lists everything as unauthorized. This does not mean that you can’t make an 837 or hcfa bill for it, it’s just a flag that lets the biller know that they have not yet checked over the line items on that fee sheet. After reviewing the fee sheets, they check the line items as authorized, and then refresh their billing report…check and make sure they authorized (reviewed) all the fee sheets, and then they can confidently fire off a claims file.
Just go to the fee sheet, and authorize the claim.
….unless I am not understanding everything here. Expound if you like
The encounter has already been submitted. The new “CPT4 Claim” was apparently entered into the encounter billing table during the processing of an ERA remittance file. The actual CPT code billed was a numeric code, not “Claim”. When I get some time and inclination, I will try and find where in the ERA processing the “CPT4 Claim” gets added. I know there is a segment in the ERA 835 for “corrected” claim information, so that is first on the list of suspects.
That DOES sound interesting.
Any chance of seeing a de-identified version of the era involved? Is it 5010? Was it 5010 going out and 4010 coming back or…?
What version/patch of openemr, x12 settings etc?
For the claim in question, the Primary Insurance reported the claim, allowed amount, payment, and patient responsibility correctly. However, the Secondary Insurance reported too high an adjustment,
with a CAS segment PI = “payor initiated reductions.” They paid the correct amount and netted it out correctly also. Personally, I think their 835 was not put together right.
I suppose the main point I can make here is that Secondary Insurance payments should not be making modifications to the claim data in any case I can imagine.
IMHO, the parse_era_inc.php does not check enough before making these changes. In this case, the BPR segment listed the payment correctly and the payment adjustments netted out to the actual payment, which was also the amount remaining from the Primary Insurance payment. Looking only at the the Service Adjustments and Payment Adjustments lead to the erroneous choice of modifying the claim data.