(Medicare Claims Processing Manual)

Prior to October 6, 2008, all A/B MACs and DME MACs shall update any of their provider customer service materials geared towards crossover claims related inquiries to reflect the newly developed BN by -pass value, which designates tha t CWF auto -excluded the claim because it contained a placeholder provider value.   The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to reflect the new BN code.   G.  New CWF Requirements for Other Federal Payers   Effective with October 3, 2011, the CWF maintainer shall expand its logic for Other Insurance, which is COIF element 176, to include TRICARE for Life (COBA ID 60000 -69999) and CHAMPVA (COBA ID 80214), along with State Medicaid Agencies (70000- 79999), as entities eligible for this exclusion.  Through these changes, if either TRICARE for Life or CHAMPVA wishes to invoke the Other Insurance exclusion, and if element 176 is marked on the COIF for these entities, CWF shall suppress claims from the national COBA crossover process if it determines that the beneficiary has active additional supplemental coverage.   As part of this revised Other Insurance logic for TRICARE and CHAMPVA, CWF shall interpret additional supplemental coverage as including entities whose COBA identifiers fall in any of the following ranges:   00001- 29999 (Supplemental);  30000- 54999 (Medigap eligibility- based);  80000- 80213 (Other Insurer); and  80215- 88999 (Other Insurer).   The Other Insurance logic for State Medicaid Agencies includes all of the following COBA ID ranges:   00001- 29999 (Supplemental);  30000- 54999 (Medigap eligibility- based);  60000- 69999 (TRICARE);  80000- 80213 (Other Insurance)  80214 (CHAMPVA)  80215- 88999 (Other Insurer).    NOTE:  As of October 3, 2011, CWF shall now omit COBA ID range 89000-89999 as part of its Other Insurance logic for State Medicaid Agencies.   CWF shall mark claims that it excludes due to Other Insurance with crossover disposition indicator M when storing them within the CWF claims history screens.  (See 80.5 of chapter 27 for additional information concerning this indicator.)  II. A/B MAC and DME MAC Actions Relating to CWF Claims Crossover Inclusion or Inclusion/Exclusion Logic   A.  Inclusion of Two Categories of Mass Adjus tment Claims for Crossover Purposes   All A/ B MACs and DME MACs shall continue to identify mass adjustment claims -MPFS and mass adjustment claims other by including an M (mass adjustment claimsMPFS) or O (mass adjustment claims other) within the heade r of the HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claim transactions, as specified in Pub.100-04, chapter 27, 80.6.  (Refer to Pub.100-04, chapter 27, 80.8 for CWF specific requirements relating to the unique inclusion of mass adjustment claims for crossover purposes.)  Effective January 5, 2009, the BCRC, at CMSs direction, modified the COIF to allow for the unique inclusion of mass adjustment claims MPFS updates and mass adjustment claims other.  The CWF maintainer shall 1) create these new fields, along  with accompanying 1- byte file displacement, within its version of the COIF; and 2) accept and process these new fields when the BCRC transmits them as part of its regular COIF updates.  Upon receipt of a HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim transac tion that contains an M or O mass adjustment indicator, CWF shall undertake all additional actions with respect to determination as to whether the claim should be included or excluded for crossover purposes as specified in chapter 27, 80.8.  A/B MAC a nd DME MAC Flat File Requirements   Before the A/B MAC and DME MAC shared systems send mass adjustment claims MPFS to the BCRC via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:  1)  Populate ADD in the field that corresponds to NTE01; and  2)  Populate MP, utilizing bytes 01 through 02, in the field that corresponds to NTE02.  Before the A/B MAC and DME MAC shared systems send mass adjustment claims other to the BCRC  via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the 837 COB flat file only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:  1)  Populate ADD in the field that corresponds to NTE01; and  2)  Populate MO, utilizing bytes 01 through 02, in the field that corresponds to NTE02.  B.  Inclusion and Exclusion of Recovery Audit Contractor (RAC)- Initiated Adjustment Claims   Effective January 5, 2009, at CMSs direction, the BCRC modified the COIF to allow for the unique inclusion and exclusion of RAC- initiated adjustment claims.  The CWF maintainer shall 1) create these new fields,  along with accompanying 1- byte file dis -placement, within its version of the COIF; and 2) accept and process these new fi elds when the BCRC transmits them as part of its regular COIF updates.  In addition, the CWF maintainer shall create a 1 -byte RAC adjustment value in the header of its HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claims transactions (valid values=R or spaces).   Through this instruction, all A/B MAC and DME MAC shared systems shall develop a method for uniquely identifying all varieties of RAC -requested adjustments, which occur as the result of post- payment review activities.   NOTE :  Currently, fewer than five ( 5) MACs process RAC adjustments.   Prior to sending its processed 11X and 12X type of bill RAC- initiated adjustment transactions to CWF for normal verification and validation, the A/B MAC (Part  A) and A/B MAC (Part HHH) shared system shall input the R indicator in the newly defined header field of the HUIP claim transaction if the RAC adjustment claim meets either of the following conditions:   1) The claim resulted in Medicare changing its payment decision from paid to denied (i.e., Medicare paid $0.00 as a result of the adjustment performed) ; or  2) The claim resulted in a Medicare adjusted payment that falls below the amount of the inpatient hospital deductible.  Prior to sending RAC- initiated adjustment claims with all other type of bill designations to CWF for normal processing, the A/ B MAC (Part  A) and A/B MAC (Part HHH) shared system shall input an R indicator in the newly defined header field of the HUOP, HUHH, and HUHC claim.  Prior to sending their processed RAC adjustment transactions to CWF for normal verification and validation, the A/B MAC (Part  B) and DME MAC shared systems shall input the R indicator in the newly defined header field of the HUBC and HUDC claim transactions.   Unique COBA ID Assignment to Trading Partners That Accept RAC -Initiate d Adjustment Claims Only and Attendant A/B MAC and DME MAC Responsibilities   The BCRC will assign a unique COBA ID range (88000-88999) to COBA trading partners that elect to include RAC -initiated adjustment claims for crossover purposes and will not, at CMSs direction, charge the trading partner the standard crossover fee for that category of adjustment claims.  Therefore, when A/B MACs and DME MACs receive a BOI reply trailer (29) on a claim that contains only a COBA ID in the range 88000 through 88999 (which designates RAC adjustment), the A/B MAC and DME MAC shall not expect payment for the claim.   Before the A/B MAC and DME MAC shared systems send tagged RAC -initiated adjustment claims to the BCRC via an ASC X12 837 flat file transmission, they shal l take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file only if there was not  a pre-existing 2300 NTE segment on the incoming Medicare claim:  1)  Populate ADD in the field that corresponds to NTE01; and  2)  Populate RA, utilizing bytes 01 through 02, in the field that corresponds to NTE02.  III.  CWF Crossover Processes In Association with the Coordination of Benefits Contractor  A.  CWF Processing of the COBA Insurance File (COIF) and Returning of BOI Reply Trailers    Effective July 6, 2004, the BCRC began to send initial copies of the COBA Insurance File (COIF) to the nine CWF host sites.  The COIF contains specific information that will identify the COBA trading partner, including name, COBA ID, address, and tax identification number (TIN).  It also contains each trading partners claims selection criteria along with an indicator (Y=Yes or N=No) of whether the trading partner wishes its name to be printed on the Medicare Summary Notice (MSN).  Effective with the October 2004 systems release, the COIF also contains a 1 -digit Test/Production Indicator that will identify whether a COBA trading partner is in test (T) or production (P) mode.  The CWF shall return that information as part of the BOI reply trailer (29) to A/B MACs and DME MACs.  Upon receipt of a claim, CWF shall take the following actions:   Search for a COBA eligibility record on the BOI auxiliary record for each beneficiary and obtain the associated COBA ID(s) [ NOTE:   There may be multiple COBA IDs associated with each beneficiary.];   Refer to the COIF associated with each COBA ID NOTE :  The CWF shall pull the COBA ID from the BOI auxiliary record to obtain the COBA trading partners name a nd claims selection criteria;    Apply the COBA trading partners selection criteria; and   Transmit a BOI reply trailer to the A/B MAC and DME MAC only if the claim is to be sent, via 837 COB flat file or NCPDP file, to the BCRC to be crossed over.  B.  BOI Reply Trailer and Claim- based Reply Trailer Processes    1.  BOI Reply Trailer Process   For eligibility file -based crossover, all A/B MACs and DME MAC s shall send processed claims information to the BCRC for crossover to a COBA trading partner in response to the receipt of a CWF BOI reply trailer (29).  A/B MACs and DME MACs will only receive a BOI reply trailer (29) under the consolidated crossover process for claims that CWF has selected for crossover after reading each COBA trading partners claims selection criteria as reported on the weekly COIF submission.  When a BOI reply trailer (29) is received, the COBA assigned ID will identify the type of crossover (see the Data Elements Required for the BOI Aux File Record Table in Chapter 27, 24).  Although each COBA ID will consist of a five -digit prefix that will be all zeroes, A/B MACs and DME MACs are only responsible for picking up the last five digits within these ranges, which will be right justified in the COBA number field.  In addition to the trading partners COBA ID, the BOI reply trailer shall also include the COBA trading partner name (s), an A crossover indicator that specifies that the claim has been selected to be crossed over, and a one- digit indicator [Y=Yes; N=No] that specifies whether the COBA trading partners name should be printed on the beneficiary MSN.  As discussed above, effective with the October 2004 systems release, CWF shall also include a 1 -digit Test/Production Indicator on the BOI reply trailer (29) that is returned to the A/B MACs and DME MACs .   MSN Crossover Messages   Effective with the October 2004 systems release, the A/ B MACs and DME MACs began to receive BOI reply trailers (29) that contain an MSN indicator Y (Print trading partner name on MSN) or N (Do not print trading partner name on MSN).