(Medicare Claims Processing Manual)

Scenario 2:  If a provider, physician/practitioner, or supplier s ubmits a HIPAA ASC X12 837 future version institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains a P current, in use version Test/Production indicator and an N future version indicator, the affected shared systems shall:  1) produce a skinny non -SFR production claim in the ASC X12 current, in use version 837 COB flat file for transmission to the BCRC; and 2) produce nothing in terms of an ASC X12 837 future version COB flat  file.  Scenario 3:  If a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837  future version institutional or professional claim to an A/B MAC or DME MAC and if that entity  receives a CWF BOI reply trailer (29) that contains an N current, in use version Test/Production indicator and a T future version  indicator, the affected shared system shall:  1) produce nothing in terms of a current version ASC X12 837 COB flat  file; and 2) produce a  future version  test claim with full S FR content for COBA testing purposes.  Scenario 4:   If a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837 future version  institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an N current, in use version Test/Production indicator and a P future version indicator, the affected shared system shall:  1) produce nothing in terms of a current, in use version ASC X12 837 COB flat file; and 2) produce a production future version  claim with full SFR conte nt for COBA production purposes.  (NOTE:  Scenario 4 will be the profile of a COBA trading partner that has cut -over to the future version ASC X12 837 COB production.)   INCOMING HIPAA ASC X12 837 CURRENT, IN USE VERSION CLAIMS IN ASSOCIATION WITH COBA TRADING PARTNER COB FORMAT SPECIFICATIONS   Scenario 1:  During the transitional period, if a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or DME MAC a nd if that entity receives a CWF BOI reply trailer (29) that contains a P current version Test/Production indicator and a T future version indicator, the affected shared systems shall: 1) create an 837 COB flat file that contains full current version S FR content for the production claim for transmission to the BCRC; and 2) create a skinny non- SFR claim in the future version ASC X12 837 COB flat file format for the test future version claim and transmit the file to the BCRC.   Scenario 2:  If a prov ider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or  DME MAC, as appropriate, and if that entity receives a CWF BOI reply trailer (29) that contains a P current version Test/Production indicator and an N future version indicator, the affected shared systems shall:  1) create an 837 COB flat file that contains full current version SFR content for the production claim; and 2) create nothing in terms of a  future version COB claim.  Scenario 3:  If a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC ( A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an N current version Test/Production indicator and a T future version  indicator, the affected shared systems shall:  1) create nothing in terms of a current use version COB claim; and 2) create a test future version non -SFR COB claim.   Scenario 4:  If a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH),  or DME MAC and if that entity receives a Common Working File (CWF) Be neficiary Other Insurance (BOI) reply trailer (29) that contains an N current version  Test/Production indicator and a P future version  indicator, the affected shared systems shall:  1) create nothing in terms of a current version COB claim; and 2) cre ate a production future version non- SFR COB claim.   SPECIAL ONGOING RULE FOR ADJUSTMENT CLAIMS, CLAIMS HELD IN SUSPENSE, AND CLAIMS TO BE REPAIRED  The shared system shall produce a future version skinny claim, without SFR content, in the event that a claim that an A/B MAC or DME MAC originally adjudicated in the current version format is later released from suspense status or is adjusted during a time frame when a COBA trading partner has moved to the ASC X12 837 future version production (that is, the  BOI reply trailer 29 contains a P future version Test/Production indicator).   In addition, as of the mandatory cutover date to the future version claim transaction, all shared systems shall have the capability of repairing claims that previously errored out in the current version format prior to the cutover date, doing so in the future version COB claim format on and after January 1, 2012.   ADDRESSING INCOMING PAPER CLAIMS FOR OUTBOUND COB PURPOSES   Scenario 1:  During the transitional period, if a provider, physician/practitioner, or supplier submits a hard- copy claim (paper Form CMS -1450 or Form CMS -1500) or, as applicable, enters a direct -data- entry (DDE) claim to an A/B MAC (A), A/B MAC (HH),  or DME MAC and if that entity receives a CWF BOI repl y trailer (29) that contains a P current version Test/Production indicator and a T future version indicator, the affected shared system shall:  1) produce a skinny non- SFR current version production COB claim; and 2) produce a skinny non- SFR futu re version test COB claim.   Scenario 2:  If a provider, physician/practitioner, or supplier submits a hard- copy claim (paper Form CMS -1450 or Form CMS -1500) or, as applicable, enters a DDE claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that ent ity receives a CWF BOI reply trailer (29) that contains a P current version Test/Production indicator and an N future version indicator, the affected shared system shall:  1) produce a skinny non-SFR current version production COB claim; and 2) produce nothing in terms of a future version COB claim.  Scenario 3:  If a provider, physician/practitioner, or supplier submits a hard- copy claim (paper Form CMS -1450 or Form CMS -1500) or, as applicable, enters a DDE claim to an A/B MAC (A), A/B MAC (HH), or  DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an N current version Test/Production indicator and a T future version indicator, the affected shared system shall:  1) produce nothing in terms of a current version claim; and 2) produce a skinny non- SFR future version test COB claim.    Scenario 4:  Finally, if a provider, physician/practitioner, or supplier submits a hard-copy claim (paper Form CMS -1450 or Form CMS-1500) or, as applicable, enters a DDE claim to an  A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity a CWF BOI reply trailer (29) that contains an N current version Test/Production indicator and a P future version indicator, the affected shared system shall:  1) produce nothing in terms of a current version COB claim; and 2) produce a skinny non-SFR future version production COB claim.  IMPORTANT:   For all scenarios, if the inbound claims format is the same as the outbound claim, the shared system shall produce crossover claims with full SFR clai m content as part of their A/B MACs (A,B, HH) or DME MACs ASC X12 837 COB flat file transmissions to the BCRC.  II. General ASC X12 837 COB Flat File Mapping Requirements (Effective July 2012)  A. ASC X12 837 Institutional COB Claim Mapping Rules  Effective with the testing and implementation of the HIPAA ASC X12 837 institutional claim (new and now current version), the Fiscal Intermediary Shared System (FISS) shall observe the following business rules for mapping of the ASC X12 837 COB (institutional) flat file:  1. The following segments shall not  be passed to the BCRC:   a. ISA (Interchange Control Header Segment); b. IEA (Interchange Control Trailer Segment);   c. GS (Functional Group Header Segment); and  d. GE (Functional Group Trailer Segment).   2. The shared system shall map the claim version (version 005010X223A2 upon adoption of the 5010 Errata changes) in the field of the ASC X12 837 5010 COB flat file that corresponds to the ST03 segment.   3. The BHT02 (Beginning of the Hierarchic al Transaction Transaction Set Purpose Code) shall be passed either with value 00 or 18 under the following circumstances:   a. Normal claims submission to the BCRC use 00; and  b. COBA claims repair process use 18.  4. The BHT03 (Beginning of the Hierar chical Transaction Reference Identification or Originator Application Transaction ID) shall contain identifiers populated as follows:  a. 23 bytes for non- COBA recovery claims as follows:    Bytes 1 -9A/B MAC (A or HH) ID (9 bytes; A/B MAC (A or HH) ID, or, 5 bytes left justified, followed by 4 spaces); Bytes 10-14Julian Date (5 bytes, expressed as YYDDD);  Bytes 15-19Sequence Number (5 bytes, starting with 00001; should increment for each ST -SE envelope); Bytes 20-21Claim Version Indicator (2 bytes; value =50 for 5010 claims); and  Byte 22Test/Production Indicator (1 byte; valid values=Ttest; Pproduction). Byte 23O riginal ve rsus Adjust ment Claim  Indic ator (1 byte) Valid val ues: Efor re processed c laims that for merly include d an electronic prescribing (e-RX) ne gative adjust ment amount;  Ofor original claim s;  P fo r Afford able Care Act or othe r congressional imperativ e mass adjustments;  Mf or non-A ffordable Care Act mass adjustments tied to Medicare Physici an Fee Sched ule (MPFS) ;Sfor mass adjustment claimsall oth ers; Rfo r RA C adjustm ent claim s;  Afo r routine adjustment claim s, not previousl y classified;  Additionally, as of April 7, 2014:  C  for CMS -directed mass adjustment action (use specified by CMS).   Vfor void/cancel only claim   b. 23 bytes for COBA recovery claims as follows:  Bytes 1 -9A/B MAC (A or HH) ID (9 bytes; A/B MAC (A or HH) ID, or, 5 bytes left justified, followed by 4 spaces); Bytes 10-14Julian Date (5 bytes, expressed as YYDDD);  Bytes 15-19Sequence Number (5 bytes, starting with 00001; should increment for each ST -SE envelope); Bytes 20-21Claim Version Indicator (2 bytes; values=50 for 5010 claims); and  Byte 22COBA recovery indicator (1 byte; indicator =R). Byte 23O riginal ve rsus Adjust ment Claim  Indic ator (1 byte) (NOTE: For valid valu es see II.A .4.a directly above.)   5. The 1000- A PER (Submitter EDI Contact Information) shall be populated as follows:   a. PER01 populate 1C;  b. PER02 populate BCRC EDI Department;  c. PER03 populate TE; and  d. PER04 populate 6464586740.