evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
Upon receipt of a claim that contains entry code 1 or action code 1 with a header value of A, the CWF shall take the follow ing actions:  Verify that, as per the COIF, the COBA trading partner wishes to exclude either adjustments, monetary adjustments, non-monetary, or both ; and    Suppress the claim if the COBA trading partner wishes to exclude either adjustments, monetary adjustments, non-monetary, or both .  NOTE:   The expectation is that such claims do not represent mass adjustments tied to the MPFS or mass adjustments -other.  If A/ B MACs and DME MACs receive a BOI reply trailer (29) on a claim that had an A indicator set in its header, the A/B MACs or DME MACs systems shall ensure that, as part of their ASC X12 837 flat file creation processes, they populate the 2300 loop CLM05-3 (Claim Frequency Type Code) segment with a value that designates adjustment rather than or iginal to match the 2330B loop REF*T4*Y that they create to designate adjustment claim.  If an A/B MACs or DME MACs shared system does not presently create a loop 2330B REF*T4*Y to designate adjustments, it shall not make a change to do so as part of this instruction.  Correcting Invalid Claim Header Values Sent to CWF  If A/B MACs and DME MACs send a value other than A, N, or spaces within the newly designated header field within their HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims, CWF shall ap ply an edit to reject the claim back to the A/B MAC or DME MAC.  Upon receipt of the CWF rejection edit, the A/B MACs or DME MACs systems shall correct the invalid value and retransmit the claim to CWF for verification and validation.  D.  CWF Identifica tion of National Council for Prescription Drug Claims
(Medicare Claims Processing Manual)
Currently, the DME MAC shared system is able to identify, through the use of an internal indicator, whether a submitted claim is in the National Council for Prescription Drug Programs (NCPDP) format.  Effective with January 2005, the DME MAC shared system shall pass an indicator P to CWF in an available field on the HUDC query when the claim is in the NCPDP format.  The indicator P should be included in a field on the HUDC that is separate from the fields used to indicate whether a beneficiary is liable for all services that are  completely denied on his/her claim.  The CWF shall read the new indicators passed via the HUBC or HUDC queries for purposes of excluding 100 percent denied claims with or wit hout beneficiary liability and NCPDP claims.  After applying the claims selection options, CWF will return a BOI reply trailer (29) to the A/B MAC or DME MAC only in those instances when the COBA trading partner expects to receive a Medicare processed clai m from the BCRC.   Effective with July 2007, CWF shall reject claims back to DME MACs if their HUDC claim contains a value other than P in the established field used to identify NCPDP claims.  E.  CWF Identification and Auto -Exclusion of ASC X12 837 Professional Claims That Contain Only Physician Quality Reporting Initiative (PQRI) Codes   Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUBC claim transmission for a 1-byte PQRI indicator (valid values=Q or space).  In addition, CWF shall create a 2 -byte field on page 2 of the HIMR claim detail in association with the new category COBA Bypass for the value BQ, which shall designate that CWF auto -excluded the claim because it contained only PQRI codes (see 80.5 of  this chapter for more details regarding the bypass indicator).  Prior to transmitting the claim to CWF for normal processing, the A/B MAC (Part B) shared system shall input the value Q in the newly defined PQRI field in the header of the HUBC when all  service lines on a claim contain PQRI (status M) codes.
(Medicare Claims Processing Manual)
Upon receipt of a claim that contains a Q in the newly defined PQRI field (which signifies that the claim contains only PQRI codes on all service detail lines, CWF shall auto- exclude the claim from the national COBA eligibility file -based and Medigap claim -based crossover processes.  Following exclusion of the claim, CWF shall populate the value BQ in association with the newly developed COBA Bypass field on page 2 of the HIMR A/B MAC (Part B) and DME MAC claim detail screens.   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 BQ by -pass value, which de signates that CWF auto -excluded the claim because it only contained PQRI codes.   The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to reflect the new BQ code.   F.  CWF Identification and Exclusion of Claims Containing Placeholder National Provider Identifiers (NPIs)   Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claims transactions for a new 1 -byte NPI- Placeholder fiel d (acceptable values=Y or space).   In addition, the CWF maintainer shall create space within page two (2) of the HIMR detail of the claim screen for 1) a new category COBA Bypass; and 2) a 2 -byte field for the indicator BN.  (See Pub. 100-04, chapter 27, 80.5 for more details regarding the BN bypass indicator.)  NOTE:   With the implementation of the October 2008 release, the CWF maintainer shall remove all current logic for placeholder provider values with the implementation of this new solution for identifying claims that contain placeholder provider values.   As A/B M ACs and DME MACs adjudicate non VA MRA claims that fall within any of the NPI placeholder requirements, their shared system shall take the following combined actions:
(Medicare Claims Processing Manual)
As A/B M ACs and DME MACs adjudicate non VA MRA claims that fall within any of the NPI placeholder requirements, their shared system shall take the following combined actions:   1) Input a Y value in the newly created NPI Placeholder field on the HUIP, HUOP, HUH H, HUHC, HUBC, or HUDC claim transaction if a placeholder value exists on or is created anywhere within the SSM claim record. NOTE :  The A/B MAC and DME MAC shared systems shall include spaces within the NPI Placeholder field when the claim does not cont ain a placeholder NPI value; and   2) Transmit the claim to CWF, as per normal requirements.   Upon receipt of claims where the NPI Placeholder field contains the value Y, CWF shall auto -exclude the claim from the national COBA crossover process.  In addi tion, CWF shall  populate the value BN in association with the newly developed COBA Bypass field on page 2 of the HIMR Part B and DME MAC claim detail screen and on page 3 of the HIMR intermediary claim detail screen.  (See Pub.100- 04, chapter 27, 80.4 for more details.)   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.
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
 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).
(Medicare Claims Processing Manual)
When a COBA trading partner is in full production (Test/Production Indicator=P), the A/ B MAC  and DME MAC shall read the MSN indicator returned on the BOI reply trailer (29).  If the A/B MAC or DME MAC receives an MSN indicator N, it shall print its generic crossover message(s) on the MSN rather than including the trading partners name.  Examples of exi sting generic MSN messages include the following:    (For all COBA ID ranges other than Medigap)   MSN #35.1 -  This information is being sent to private insurer(s).  Send any questions regarding your benefits to them.    (For the Medigap COBA ID range)   MSN #35.2 -  We have sent your claim to your Medigap insurer.  Send any questions regarding your Medigap benefits to them.   Beginning with the October 2004 systems release, A/B MACs and DME MACs shall follow these procedures when determining whether to update  its claims history to show that a beneficiarys claim was selected by CWF to be crossed over.    If the A/B MAC or DME MAC receives a BOI reply trailer (29) that contains a Test/Production Indicator T, it shall not update its claims history to show that a  beneficiarys claim was selected by CWF to be crossed over.    If the A/B MAC or DME MAC receives a BOI reply trailer (29) that contains a Test/Production Indicator P, it shall update its claims history to show that a beneficiarys claim was selected by C WF to be crossed over.    Effective January 5, 2009, when CWF returns a BOI reply trailer (29) to an A/B MAC and DME MAC that contains only a COBA ID in the range 89000 through 89999, the A/B MAC and DME MAC shared system shall suppress all crossover information, including name of insurer and generic message#35.1, from all beneficiary MSNs.   A/B MACs and DME MACs shall not update their claims histories to reflect transference of tagged claims with COBA ID range 89000 through 89999 to the B CRC.
(Medicare Claims Processing Manual)
A/B MACs and DME MACs shall not update their claims histories to reflect transference of tagged claims with COBA ID range 89000 through 89999 to the B CRC.   ASC X12 835 (Electronic Remittance Advice)/ Provider Remittance Advice Crossover Messages   Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a T Test/Production Indicator to the A/B MACs and DME MACs, they shall not print information received from the BOI reply trailer (29) in the required crossover fields on the ASC X12 835 Electronic Remittance Advice or other provider remittance advices that are in production.  Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a P Test/Production Indicator to the A/B MACs and DME MACs, they shall use the returned BOI trailer information to take the following actions on the providers 835 Electronic Remittance Advice:   a. Input code 19 in CLP -02 (Claim Status Code) in Loop 2100 (Claim Payment Information) of the 835 ERA (v. 4010- A1). [ NOTE:  R ecord 20 in CLP -02 (Claim Status Code) in Loop 2100 (Claim Payment Information) when Medicare is the secondary payer.]   b. Update the 2100 Loop (Crossover Contractor Name) on the 835 ERA as follows:    NM101 [Entity Identifier Code] Use TT, as specified in the 835 Implementation Guide.    NM102 [Entity Type Qualifier] Use 2, as specified in the 835 Implementation Guide.    NM103 [Name, Last or Organization Name] Use the COBA trading partners name that accompanies the first sorted COBA ID returned to you on the BOI reply trailer.   NM108 [Identification Code Qualifier] Use PI (Payer Identification)    NM109 [Identification Code] Use the first COBA ID returned to you on the BOI reply trailer.  (See line 24 of the BOI aux. file record
(Medicare Claims Processing Manual)
 NM109 [Identification Code] Use the first COBA ID returned to you on the BOI reply trailer.  (See line 24 of the BOI aux. file record   Effective with January 5, 2009, if CWF returns only COBA ID range 89000 through 89999 on a BOI reply trailer (29) to an A/B MAC and DME MAC, the assoc iated shared  system shall suppress all crossover information (the entire 2100 loop) on the 835 ERA.   CWF Sort Routine for Multiple COBA IDs   Effective with October 3, 2011, when a beneficiarys claim is associated with more than one COBA ID (i.e., the beneficiary has more than one health insurer/benefit plan that pays after Medicare), CWF shall sort the COBA IDs and trading partner names in the following order on the returned BOI reply trailer (29): 1) Eligibility -based Medigap (30000- 54999); 2) Medigap claim -based (55000- 59999); 3) Supplemental (00001- 29999); 4) Other Insurer (80000- 80213); 5) Other Insurance (80215- 88999); 6) TRICARE (60000- 69999); 7) CHAMPVA (80124); 8) Medicaid (70000 -79999); and 9) Other -Health Care Pre- payment Plan [HCPP] (89000- 89999).  When two or more COBA IDs fall in the same range (see element 24 of the Data Elements Required for the BOI Aux File Record Table in chapter 27, 80.4 for more details), CWF shall sort numerically within the same range.   IV. A/B MAC and DME MAC Act ions Relating to the Transition to the ASC X12 837 Version 5010 and NCPDP Version D.O   A.  CWF COIF and BOI Reply Trailer (29) Processes