We are having difficulty with submitting patients that are Blue Cross Blue Shield of Florida to Availity. The Error message we are getting is sender code is invalid with an Error Code of Webv010. Upon calling Availity they stated it had to do with Loop 1000A NM109 and to to contact our vendor for assistance. The value that was being submitted we were told by Availity was our Tax ID number. We were told it should be the Blue Cross Blue Shield of Florida Sender Submitter ID.
We have tried to setup a secondary X12 partner with the BCBS FL Submitter Id as the ID ETIN number but received the same error. We would like to know how to fix this problem. We are currently using Open EMR 4.1.1 on Windows using the Xampp Package. We are not having this problem with any other insurance carriers. If you need more information please respond to this post.
.
Thank you,
Steven
This is the relevant code section that generates Loop1000A. It looks like NM109 is normally the billingFacilityETIN as you say, but when using eClaims as a clearing house some added a special case to use a different ETIN.
It seems as if you might need some additional logic for BCBS FL. Do you have a “Blue Cross Blue Shield of Florida Sender Submitter ID” assigned to your practice?
It seems as if you might need some additional logic for BCBS FL. Do you have a “Blue Cross Blue Shield of Florida Sender Submitter ID” assigned to your practice?
Yes we do. That number is H0064 per BCBS FL. The problem is there doesn’t seem to be a place to put this number in Open EMR. In the X12 Partner Section there is no Secondary Submitter ID field. I have also tried to use the insurance numbers section to place it in the provider field with the sub field specified as 1B Blue Cross. If need be I can enter any additional logic or information to the file you quoted.
The problem is there doesn’t seem to be a place to put this number in Open EMR.
Your assessment is correct. That was my point in posting that code block. NM109 in Loop 1000A can only be populated from the billing facility ETIN or in the very special case of eClaims, the clearinghouse’s ETIN is used instead.
Does BCBS still want your ETIN in other locations in the X12 file? If not, one solution that might work is to create a separate facility that has H0064 instead of your ETIN and choose that facility when billing for BCBS FL.
If that doesn’t work, I’m not sure you are going to be able to accomplish what you want without changes to the .PHP code.
I suggest you try to manually edit a batch file to see if it works with the BCBS FL ID number. Reopen the one claim and generate a new batch. Use a plain text editor like notepad or a programmer editor (be sure you are not using some unicode font scheme that inserts a byte order mark code at the very beginning of the file). Find the loop 1000A NM1 segment with search “NM1*41*” and then move to “*46*” which should be followed by the ID number, which can be edited to be whatever you think it should be.
Yehster - IMHO, this may be a candidate for your project funding scheme. The batch generation process is enough spaghetti code to discourage hackers like me, but not really broad enough to cover the possibilities. Does the Claim_class have the needed value?
We had a similar problem setting up with Medicare. Our BCBS FL ID was entered under Administration > Practice > Insurance Numbers. And, with the Provider Type set to “1B Blue Cross” it was being rejected. Try leaving the Provider Type “unspecified” That is what made it work for us.
Thank you for your help. I wanted to inform you what has happened since our last post.
We did make the change manually to the NM1 segment and the claim went further along the processing chain. However, when we attempted to create another facility with another patient using H0064 as the ETIN we encountered a REF2 error. It seems the ETIN number is sent twice. The second location needs to be our Tax ID rather than the BCBS FL Submitter code.
Additional, when we manually edited the 5010 edi form we discovered that the information placed into the Insurance Numbers section is not submitted. We believe the insurance number section only applies to the 1500 form.
At this time we only see one way to correct our problem and that is by manually editing the edi prior to submitting to Availity only for BCBS FL patients.
I would think that there would be enough submissions to BCBS FL to warrant a change in code to allow for a place to put a secondary submitter id.
We use two different “facilities” that are billing locations. One is also a service location.
The other facilities are not billing locations. They do not have ETIN’s. They just amount to a location POS code.
The billing facilities each have a TIN and a group NPI.
In the encounter, the labels are changed to “Location” and “Billing Facility” To get the results of things like “Home” and “Our clinic”.
As for the x12 config, does your configuration look like the attached file?
ISA06 = AV09311993
GS02 = AV01101957
We bill Florida Blue with this.
I added a Billing Notes column to the Billing Report. It takes the patient (not encounter) billing notes that are normally entered through the payment manager and displayed on the patient dashboard and listed them next to the java portion of the billing manager line items. Perhaps you would like that modification?
Correction:
Per Florida Blue 837P Companion Guide, GS02 is the " Florida Blue assigned Sender Code", page 13 and ISA06 is “your individually assigned Florida Blue sender mailbox number”, page 12.
OK, I am embarrassed.
I overlooked a hard-coded exception for Florida Blue that I had already made some time ago. Like the E-claims exception, hard-coded exceptions is frankly not the way to get things done. These bastards are muddying the waters. Getting them to un-mash the mash up is not a likely outcome, but screaming ought to be done.
On the OpenEMR side, I would argue for the creation of a gen_x12_exceptions_for_assholes.inc file. This should further be linked to some database table to provide configurable quid-pro-quo logic. This would call for a conditional statement before each element is appended to the 837 file being generated. The primary piss-off is the fact that we are not talking about loop element tweaks here. We are talking about header values. That pretty much damns all Florida Blue claims to having their own file, even if every other InsCo in your list can be sent to the same clearinghouse in one lump. Currently, sorting criterion by X12 partner does not work for unbilled claims in the Billing Report (Billing Manager). It only works for sorting stuff that is already paid. This brushes on the issue that the criteria selection section of the billing report and it’s includes is flawed in scope and implementation, as default search criteria and configuration of the same is very much a hard-code option only. There is also something funny going on with trying to add a drop-down element to the criteria selection scheme it uses.
In any case, when you run billing export, you SHOULD be able to sequentially or simultaneously obtain files for each default or selected x12 partner pretty much automatically. This prevents input error, and speeds up a common task that is done day after day, or (for us) at least a weekly thing. Balance this against a one-time code upgrade (“UpGrayedd, with a double D for a Double Dose!” -IDIOCRACY), and is seems pretty reasonable. Folks have already worked configuring the patient, billing data, entering fee sheets, and verifying the claims individually. It’s a shame that we have to fiddle around with selecting, exporting and importing at all. It should be a matter of hitting a button and checking your bank account. When we run into idiot situations like this Florida Blues Band gang, we should use it as an opportunity to make the system more robust overall. There are a lot of jack-wagon operations out there.
In closing, one more note about the Billing Report.
While selection criteria is important, sorting order is not less so. The DEFAULT sort for the report should be
X-12 default or selected
Insurance company
Patient name (or PID, or PUBPID if my MUST) or service data)
Sorting criteria should be selectable the same as selection criteria. Default sorting and selection should be stored per-user (in a table only configured for billing report user IDs)
Why would you need a new facility??? we have several facilities for different POS codes, as well as separate programs and group NPI’s, but what is it doing in this situation?
x12 partner we understand. ISA06 and GS02 must match.
if (trim($claim->x12gsreceiverid()) == ‘470819582’) { // if ECLAIMS EDI
$out .= “*” . $claim->clearingHouseETIN();
} else {
if ($claim->payerID()==‘00590’) {
$out .= “HC279";
}else{
$out .= "” . $claim->billingFacilityETIN();
}}
The HC279 is our Florida Blue number. I just checked that this is working for us.
This (using your number) edited into your genx12 include should work for you…in the meantime.
What we need is a Loop1000A exception field in the insurance company bit. NOTHING ELSE needs to be changed in the X12 partner, the facility, or any of that stuff.
I have made changes for the x12 configuration before, re-writing the layout and adding some of the fields in the current version, but I have never dug into the files that feed the insurance company input. I think they are similar (possibly nearly identical), so I should be able to add a field to contain this Florida Blue ID number, complete with an alt-text warning to not use it unless you know why. If this field is not null, the loop for the claim will process using the value, else use the ETIN.
Now here is the real question: IF some poor bastard out there uses ECLAIMS EDI and trying to bill Florida Blue…?
And yes, Kevin etc… I will use switch/case/break and not nested if-else
Thanks a ton Art. I will put this in tonight and have our biller give it a
shot.
On Jul 24, 2013 8:30 PM, “Art Eaton” aethelwulffe@users.sf.net wrote:
Otay,
if (trim($claim->x12gsreceiverid()) == ‘470819582’) { // if ECLAIMS EDI
$out .= “*” . $claim->clearingHouseETIN();
} else {
if ($claim->payerID()==‘00590’) {
$out .= “HC279";
}else{
$out .= "” . $claim->billingFacilityETIN();
}}
The HC279 is our Florida Blue number. I just checked that this is working
for us.
This (using your number) edited into your genx12 include should work for
you…in the meantime.
What we need is a Loop1000A exception field in the insurance company bit.
NOTHING ELSE needs to be changed in the X12 partner, the facility, or any
of that stuff.
I have made changes for the x12 configuration before, re-writing the
layout and adding some of the fields in the current version, but I have
never dug into the files that feed the insurance company input. I think
they are similar (possibly nearly identical), so I should be able to add a
field to contain this Florida Blue ID number, complete with an alt-text
warning to not use it unless you know why. If this field is not null, the
loop for the claim will process using the value, else use the ETIN.
Now here is the real question: IF some poor bastard out there uses ECLAIMS
EDI and trying to bill Florida Blue…?
David, I will come out with a commit, then try to track down this thread in the laundry-list “Yellum” and make note of it. (Forums are organized and you can find relevant stuff, this is a Yellum, 'cause only the person currently yelling can be heard).
I am thinking that we need to retract the logic for eclaims, and put a field next to default X12 partner in the insurance that sets this field for each insurance company. It should have advice on using the field, and perhaps should put the decision logic at that level (if payerID=="*" echo"Hey dumbass, you can’t bill with that!"). I would LOVE to put in a list of clearinghouses and really help folks out. I looked into it though, and there seem to be about a billion clearinghouses. Guess not. I see NOTHING wrong with using up a little bit of the white space on the right in the insurance company and x12 configuration HTML templates to provide some FAQ’s or 'splain some stuff, and offer a “billing configuration help” link. Edge cases are best served by letting someone know that there is something they might not know vs. trying to take care of it with business logic.
Naturally, a conversion script for locating and updating insurance companies with a default ECLAIMS choice. Another option is to have both insurance and x12 level fields for dealing with this. For e-claims, you enter the other TIN there. For Florida blue, you enter the alternate in the insurance company. I just don’t like having hard-coded configurations for special cases.
BTW,
Some folks using certain other work-arounds MIGHT be running into a different issue.
If you have created a facility as a NON-BILLING location (just looking for a POS code) and you have entered an ETIN or a group NPI, and NOT both, you will get errors. If you have one of them, you must have both. We do not have logic preventing this.
I’m in total agreement with you about hard coding. The masses are left to fend for themselves, and the system looses potential capability and flexibility. Good ideas Art!
