evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
Scenario 1:  During the ASC X12 837 future version tr ansitional period, 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 Common Working File (CWF) Beneficiary Other Insurance (BOI) reply trailer (29) that contains a P current, in use version Test/Production indicator and a T future version indicator, the affected shared systems shall:  1) produce a skinny non- SFR production claim in the current, in use version  ASC X12 837 COB flat file for transmission to the BCRC; and 2) produce an ASC X12 837 future version test COB flat file that contains a claim with full SFR content for transmission to the BCRC.   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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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:
(Medicare Claims Processing Manual)
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.   6. The 1000- B loop NM1 (Receiver Name) denotes the crossover trading partner.  If an A/B MAC (A, HHH) on FISS receives multiple COBA IDs via the BOI reply trailer (29), the shared system shall submit a  separate 837 transaction for each COBA ID received.  Since crossover trading partner information will be unknown to the shared systems, the shared systems shall format the following fields as indicated:   a. NM101populate 40;  b. NM102populate 2;  c. NM103populate spaces (the BCRC will complete); d. NM108populate 46; and e. NM109include COBA ID (5 -digit COBA ID obtained from the BOI reply trailer 29).   7a. To populate the 2010AA NM1 (Billing Provider Name), FISS shall complete the segments as indicated below if the incoming claim is electronic.
(Medicare Claims Processing Manual)
7a. To populate the 2010AA NM1 (Billing Provider Name), FISS shall complete the segments as indicated below if the incoming claim is electronic.   a. NM101populate 85;  b. NM102populate 2;  c. NM103derived from A/B MAC (A or HH)s internal provider file;  d. NM108populate XX; and e. NM109populate NPI value, as derived from the incoming claim.  For 2010AA N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)s internal provider file.   7b. If the incoming claim is paper Form CMS -1450 or direct data entry (DDE), which is treated as paper, FISS shall complete the 2010AA NM1 (Billing Provider Name segments as follows:   a. NM101populate 85;  b. NM102populate 2;  c. NM103derive from the A/B MAC (A or HH)s internal provider file; d. NM108populate XX; and e. NM109derive NPI from Form Locator (FL) 56 of the Form CMS -1450 claim or applic able DDE field.    For 2010AA N3 and N4 segments, FISS shall derive the required segments from FLs 1 and 2 of the Form CMS -1450 claim or internal provider file as necessary.   8a. To populate the 2010AB NM1 (Pay- to Address Name), FISS shall complete the segm ents as indicated below if the incoming claim is electronic.   a. NM101populate 87;  b. NM102populate 2; and c. NM103derived from A/B MAC (A or HH)s internal provider file.     For 2010AB N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)s internal provider file.
(Medicare Claims Processing Manual)
For 2010AB N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)s internal provider file.   8b. If the incoming claim is paper Form CMS -1450 or direct data entry (DDE), which is treated as paper, FISS shall complete the 2010AB NM1 (Pay- to Address Name) segments as follows:   a. NM101populate 87;  b. NM102populate 2; and c.   NM103derived from incoming claim.   For 2010AB N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)s internal provider file as necessary.   9. FISS shall derive the 2010AA REF (Billing Provider -TAX ID) segments as follows, regardless of incoming claims format:   a. For REF01 populate EI; and  b.   For REF02derive from A/B MAC (A or HH)s internal provider file.   10a. For the 2000A and 2310- PRV in association with in coming electronic claims, FISS shall map the PRV01, PRV02, and PRV03 segments (which have already been validated for syntactical correctness at each affiliate A/B MAC (A or HH)s front -end) to the equivalent 837 COB flat as follows:  a. For PRV01populate  BI; b. For PRV01populate PXC; and c.    For PRV03populate taxonomy code value from incoming claim.   10b. If the incoming claim is paper Form CMS -1450 or DDE entered, FISS shall only populate the 2000A -PRV (Bill- to Taxonomy) segments within the equivalent 837 COB flat fields as follows if the reported taxonomy code is syntactically correct:   a. For PRV01populat e BI;  b. For PRV01populate PXC; and  c. For PRV03populate taxonomy code as derived from the keying of FL 81cc(a) of the Form CMS-1450 claim form or as derived from the appropriate field from the online DDE screen.
(Medicare Claims Processing Manual)
NOTE:  The only reason why the 2310A PRV cannot be included on the 837 COB flat file is that the Form CMS -1450 claim and DDE claim entry screens can only accommodate Bill -to Provider taxonomy code reporting.  11. FISS shall derive information for 2010AA PER 03, PER04, PER05, and PER06 if such information is present on the incoming electronic or paper claim or is available within the A/B MAC (A or HH)s internal provider files.  If the information is not available, or is available in incomplete form (i.e., fewer digits than required), the shared system shall not create the 2010AA PER loop within the 837 new current version COB institutional flat file.  12a. For the 2320B SBR01, in situations where there is only one (1) payer that is primary to Medicare, FISS shall apply P to any payer that is primary before Medicare; S for Medicare as the secondary payer; and U for all supplemental payers after Medicare.   SPECIAL NOTE:  If, for example, a claim contains at least two (2) primary payers before Medicare, FISS shall reflect the first payer as 2320 SBR01= P; the second as 2320 SBR01= S; and, the tertiary payer, Medicare, as 2320 SBR01=T.  FISS shall reflect all additional supplemental payers as SBR01= U.  12b. For 2000B SBR01 (element 1138), FISS shall apply P when Medicare is the primary payer and shall apply U for all other supplemental payers after Medicare.    13. For additional 2000B requirements, FISS shall take the following actions:  a) SBR03 map spaces; and  b) SBR09 map MC if the COBA ID returned via the BOI reply trailer (29)= 70000-79999; for all other COBA IDs, map CI.  14. The 2010BA loop denotes beneficiary subscriber information.  FISS shall populate this loop and accompanying segments within the equivalent 837 COB flat file fields as indicated below.      2010BA NM1Subsc riber Name:
(Medicare Claims Processing Manual)
2010BA NM1Subsc riber Name:   a.    NM101populate IL; b. NM102populate 1; c. NM103derive from internal beneficiary eligibility file;  d.    NM104derive from internal beneficiary eligibility file;  e.    NM105derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108populate MI; and  g. NM109populate the beneficiarys Medicare beneficiary identifier.     2010BA N3Subscriber Address :  a. N301derive from internal beneficiary eligibility file; and  b. N302derive, as neces sary, from internal beneficiary eligibility file; otherwise populate spaces.    2010BA N4Subscriber City/State/ZIP Code:   a. N401derive from internal beneficiary eligibility file; b. N402derive from internal beneficiary eligibility file; c. N403derive from internal beneficiary eligibility file; and  d.   N407derive if available and applicable from internal beneficiary eligibility file; otherwise populate spaces.  NOTE :   See G ap-Fill section for the valu es to be  populated on outbound C OBA crosso ver claims when the individual data conte nt for N401 (City) or N402 ( State) or N403 (Zip/Postal Code) cannot othe rwise  be d erived.  15. The shared systems shall populate the 2330A (Other Subscriber) NM1, N3, and N4 segments as follows:     2330ANM1:   a NM101populate IL; b. NM102populate 1; c. NM103derive from internal beneficiary eligibility file; d.   NM104derive from internal beneficiary eligibility file;  e. NM105derive from internal beneficiary eligibility file if available;  otherwise populate spaces; f.   NM108populate MI; and g.  NM109populate the beneficiarys Medicare beneficiary identifier .
(Medicare Claims Processing Manual)
2330A- N3:  a. N301derive from internal beneficiary eli gibility file; and  b. N302derive, as necessary, from internal beneficiary eligibility file as necessary; otherwise populate spaces.    2330A- N4:   Upon implementation of the 5010 Errata, the shared system shall not attempt to gap-fill or systems -fill any elements (N401 N407) within this segment.  Also, if these elements are available but are incomplete, the shared system shall not create the N4 segment tied to loop 2330A within the ASC X12 837 COB flat file.  a. N401derive from internal beneficiary eligibility file; and  b. N402, N403, N404, N407derive from internal beneficiary eligibility file if available and applicable; otherwise populate spaces.   16. The 2010BB loop denotes the payer name.  Per the HIPAA Implementation Guide, this loop should define the secondary payer when sending the claim to the second destination payer.  Thus, since the payer related to the COBA ID will be unknown by the A/B MAC (A or HH) shared systems, FISS shall format the NM1, N3, and N4 segments as follows, with the BCRC completing any missing information:  2010BBNM1:   a. NM101populate PR;  b. NM102populate 2; c. NM103--populate spaces; d. NM108populate PI; and  e. NM109populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).   2010BB-N3 & 2010BB- N4:  a. N301 & N302populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.  17. FISS shall not creat e the 2010AC loop within the 837 new version COB flat file.
(Medicare Claims Processing Manual)
17. FISS shall not creat e the 2010AC loop within the 837 new version COB flat file.  18. If FISS notes the presence of other payers within 2320 SBR and 2330B loops that had made no financial determination on a claim prior to Medicare, as in the case of Medicare secondary payer (MSP) situations, the shared system shall not move those loops to the 837 new version COB institutional flat file.  ( NOTE:   The shared system shall continue to populate information as received from the CWF BOI reply trailer (29) within the 2320 SBR and 2330 loops of the associated ASC X12 837 COB flat file fields.)  19. The 2330B loop denotes other payers for the claim following Medicare.  All should note that there will always be one (1) 2330B that denotes Medicare as a payer, with FISS completing all required information for NM101, NM102, NM103, NM108, NM109, as well as the N3 and N4 segments.   20. For additional 2330B loop iterations relating to COB, if the A/B MAC receives multiple COBA IDs via the BOI reply trailer (29), payer information for additional COBA IDs will be unknown.  As with the 2010BB loop, the NM1 segmen t should be formatted as follows, with BCRC completing missing information:  2nd and additional iterations of 2330BNM1:   a. NM101populate PR:  b. NM102populate 2; c. NM103populate spaces; d. NM108populate PI; and  e. NM109populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).   2nd and additional iterations of 2330B-N3 & 2330B- N4:  a. N301 & N302populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.  21. FISS shall always send at least one (1) complete iteration of 2320, 2330A, and 330B on all ASC X12 837 COB flat files.