The process for secondary claims appears to be writing a record to billing table that looks like this:
“CPT4:Claim Added by Ins2 2010-10-19” - it has a invalid CPT Code = to the word 'Claim", it also is wrtten with the ‘athorized’ field = 0.
So … this bit of code in 'billing_report.php" is triggered.
if ($iter['id'] && $iter['authorized'] != 1) {
$rhtml .= "<td><span class=alert>".xl("Note: This code was not entered by an authorized user. Only authorized codes may be uploaded to the Open Medical Billing Network for processing. If you wish to upload these codes, please select an authorized user here.")."</span></td>\n";
}
Resulting in a message that is meaningless and can’t be fixed. There is no ‘selection’ for authorized user and the claim can’t be reopened to edit (ie: delete the invalid line added by the system, apparently).
PS: whoi is “Open Medical Billing Network” anyway?
Ideas? was this fixed in a later release? work a rounds for now?
Those billing entries would be generated by processing of x12 835 (ERA) files. It’s important to always check the reports generated by that process carefully - some things it cannot handle very well.
The added entry would certainly be “unauthorized”, since no authorized user has approved it. However the support for a sensible work flow for unauthorized entries is pretty poor in my opinion and needs improvement. It’s not something I’ve delved into very much.
At this point it’s just bad. The user can’t fix it them selves. the ERA process should not write records to the billing table that effect the claims process, it’s just a bad design all together. If some indication that secondary billing is needed or whatever that’s for is required then is should be not be written as if it was some kind of service code. That will effect statistic in service reporting for instance. Bad idea all around.
It will require diving into the database tables to workaround, not good at all.
I assume that nothing in the later releases has changed that.
The ERA process, just like manual EOB entry, must affect the claims process. Secondary payers want to know what the primary payers did.
The billing table is not designed just for service codes. Some things happen at the claim level and are not tied to a specific service line. There are lots of ways to design something… there may be a better way, but failure to understand it doesn’t mean it is awful.
Tony let’s keep things polite in the public forums. Phrases like “it’s just bad” and “bad idea all around” are inflammatory.
Was not meant to be inflammatory, but it is a bad idea mix coding for services and claims status information. Particularly when it’s isn’t actually working as intended. Secondary billing is a very weak link. Billing in general needs to be rock solid and this model is, obviously, not working. I’ll be spending some quality time with this code and find a better way.
If you can’t talk about the code as produced and critique it on this forum the the forum has no purpose.
The billing table has always contained claim status information. I’ve already taken several steps to get away from that, in particular creating the “claims” table and moving some things to form_encounter. ar_session and ar_activity also play a role with this, but more on the A/R side.
A lot of effort has gone into improving what used to be a very broken billing system. Make sure you understand it before you assume something is still broken. There are people using it successfully. It’s far from perfect but improvements have been very significant.
Rejected: The Claim Adjustment Group cannot be repeated unless the previous CAS for the same Group is full.
EClaims says the rejection was because it showed two PRs in the 2430 loop. It showed that the primary paid $98.91 and also paid $24.73. $24.73 is the amount that needs to be submitted to the secondary.
– EXTRACT from LOOP 2430
SVD*05202*0.00*HC:99336**1~
CAS*CO*45*15.51~
CAS*PR*1*98.91~
CAS*PR*2*24.73~
The ‘PR’ code means ‘patient responsibility’ according to the guides
The Collection report looks correct, showing:
2010-09-08 BIlled:139.15 Adj:-15.51 Paid by Ins1:98.91 Bal:24.73
That does look odd. The $98.91 payment should show up in the SVD segment, not CAS (which is for adjustments). It would take some digging to figure out what’s going on.
99% of the secondary claims are being rejected at this customers for this issue. Any suggestions or assistance would be appreciated. This is a 3.1 OpenEMR, but I don;t think gen_x12 has changed in that area.
-Tony
Suggest you try to repro the problem at either the 3.2 or 4.0 demo site. What you’d be trying to do is make the primary payment show up in a CAS segment.
OK, did that on Demo Site, posted payment manually since create a ERA to match is not so easy.
The resulting (snipped) Secondary Claim X12 for Wallace Buckley is below
In the test it did not put two PR lines, however, but that may be because there was no adjustment type in manual EOB posting called ‘coinsurance’ which there, apparently is for 835 posts. So I did not enter any adjustments, just the payment.
I’m going to try a couple of more and also use ZHH’s payment module instead of the old one.