(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.   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.   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.     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:   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 .    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.  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.