Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Sender Code Invalid for Availity for BCBS FL

Help
J. Defoe
2012-11-08
2013-07-26
  • J. Defoe
    J. Defoe
    2012-11-08

    Hello,

      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

     
  • Kevin Yeh
    Kevin Yeh
    2012-11-08

    //Field length is limited to 35. See nucc dataset page 63 www.nucc.org
      $billingFacilityName = substr($claim->billingFacilityName(), 0, $CMS_5010 ? 60 : 35);
      $out .= "NM1" .       // Loop 1000A Submitter
        "41" .
        "
    2" .
        "" . $billingFacilityName .
        "
    " .
        "" .
        "
    " .
        "" .
        "
    46";
       if (trim($claim->x12gsreceiverid()) == '470819582') { // if ECLAIMS EDI
        $out  .=  "" . $claim->clearingHouseETIN();
       } else {
        $out  .=  "
    " . $claim->billingFacilityETIN();
       }
        $out .= "~\n";

    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?

     
  • J. Defoe
    J. Defoe
    2012-11-09

    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. 

    Thank you for your help -
      Steven

     
  • Kevin Yeh
    Kevin Yeh
    2012-11-09

    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?

     
  • David
    David
    2012-11-10

    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. 

     
  • J. Defoe
    J. Defoe
    2012-11-13

    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. 

     
  • David
    David
    2013-07-04

    We are experiencing this same issue. Any progress on this?

     
  • Art Eaton
    Art Eaton
    2013-07-08

    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?

     
    Attachments
  • fsgl
    fsgl
    2013-07-09

    The solution is then a 4 step process (using Steven's office as an example) involving:

    1. Set up Second Facility with Service Location checked and a POS Code.
    2. Set up another X12 Partner with the Sender Code in both boxes.
    3. Choose Second Facility as the Facility with each new encounter.
    4. Choose Availity-Blue Florida as the default X12 Partner for Blue Florida.

    Please point out any deficiencies or errors with the above understanding.

     
    Last edit: fsgl 2013-07-09
    Attachments
    • Art Eaton
      Art Eaton
      2013-07-24

      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.

       
  • Art Eaton
    Art Eaton
    2013-07-09

    With availity, you should have something like:

    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?

     
    Last edit: Art Eaton 2013-07-09
  • fsgl
    fsgl
    2013-07-10

    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.

     
  • Art Eaton
    Art Eaton
    2013-07-10

    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
    1. X-12 default or selected
    2. Insurance company
    3. 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)

     
    Last edit: Art Eaton 2013-07-10
  • fsgl
    fsgl
    2013-07-11

    Translation for mere mortals: Florida Blue is idiosyncractic. Use David's work-around.

     
  • Art Eaton
    Art Eaton
    2013-07-25

    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....? :)

    And yes, Kevin etc... I will use switch/case/break and not nested if-else

     
    Last edit: Art Eaton 2013-07-25
    • David
      David
      2013-07-25

      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....? :)


      Sender Code Invalid for Availity for BCBS FLhttps://sourceforge.net/p/openemr/discussion/202505/thread/d5fcaae1/?limit=25#73cd

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/openemr/discussion/202505/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       
  • Art Eaton
    Art Eaton
    2013-07-25

    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.

     
  • Art Eaton
    Art Eaton
    2013-07-25

    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.

     
    Last edit: Art Eaton 2013-07-25
  • David
    David
    2013-07-25

    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!

     
  • David
    David
    2013-07-26

    Art, Thanks to your code snippet, we're good with BC/BS FL ;o)
    No more manual editing of our BC/BS x12 batches going to Availity.

    Just a couple things to point out for those following along; This forum does not handle code posts well due to certain characters that do not show up, such as "asterisks" enclosed in quotes! (which is why Art posted a link to his code,) but not knowing that little tidbit in advance, I just copied the code out of his post and then spent several hours of head banging diagnosing why it wasn't working.

    Thanks again,

    -David

     
    Last edit: David 2013-07-26
  • David
    David
    2013-07-26

    For fellow Florida OpenEMR users with BC/BS problems using Availity; here is the code snippet with explanation on how to insert it.

     
  • Art Eaton
    Art Eaton
    2013-07-26

    David,
    So good to hear your Florida Blue claim pains are back into the realm of reasonable. Got word from Preston that their claim went through as well, but still got rejected due to then not doing Florida Blue credentialing. I told them that I saw something on Availity about credentialing via Availity...but did not look too closely. Not into multi-tasking, so I stuck to what I was doing: though I certainly have multiple tasks I am responsible for (that are late).