CMS Pub. 100-04, ch. 28, § 70.6.5

Coordination of Benefits (COB) Mapping Requirements as of July 2012

(Rev. 4281, Issued: 04- 19-19, Effective: 05-20-19, Implementation: 05-20-19)

The term Medicare beneficiary identifier (Mbi) is a general term describing a

beneficiary's Medicare identification number. For purposes of this manual, Medicare

beneficiary identifier references both the Health Insurance Claim Number (HICN) and

the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition

period and after for certain business areas that will continue to use the HICN as part of

their processes.

I. Health Insurance Portability and Accountability Act (HIPAA) 837 current, in

use version to HIPAA future version COB Transitional Period Requirements

During the ASC X12 837 transitional period, the shared systems shall accommodate the

multi-faceted scenarios that follow below each broad category with respect to creation of

ASC X12 837 COB flat files.

INCOMING HIPAA FUTURE VERSION CLAIMS IN ASSOCIATION WITH

COBA TRADING PARTNER COB FORMAT SPECIFICATIONS

Scenario 1: During the ASC X12 837 future version transitional 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 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 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 SFR 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 content 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 and 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 SFR 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 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, 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) Beneficiary

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) create 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 reply 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 future 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 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 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 claim’s format is the same as the

outbound claim, the shared system shall produce crossover claims with full SFR claim

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 Hierarchical 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 Hierarchical 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-9—A/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-14—Julian Date (5 bytes, expressed as “YYDDD”);

Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should

increment for each ST-SE envelope);

Bytes 20-21—Claim Version Indicator (2 bytes; value =50 for 5010

claims); and

Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test;

“P”—production).

Byte 23—Original versus Adjustment Claim Indicator (1 byte)

Valid values:

E—for reprocessed claims that formerly included an

electronic prescribing (e-RX) negative adjustment amount;

O—for original claims;

P— for Affordable Care Act or other congressional imperative

mass adjustments;

M—for non-Affordable Care Act mass adjustments tied to

Medicare Physician Fee Schedule (MPFS);S—for mass adjustment

claims—all others; R—for RAC adjustment claims;

A—for routine adjustment claims, not previously classified;

Additionally, as of April 7, 2014:

C – for CMS-directed mass adjustment action (use specified by

CMS).

V—for void/cancel only claim

b. 23 bytes for COBA recovery claims as follows:

Bytes 1-9—A/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-14—Julian Date (5 bytes, expressed as “YYDDD”);

Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should

increment for each ST-SE envelope);

Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010

claims); and

Byte 22—COBA recovery indicator (1 byte; indicator =R).

Byte 23—Original versus Adjustment Claim Indicator (1 byte) (NOTE:

For valid values 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. NM101—populate “40”;

b. NM102—populate “2”;

c. NM103—populate spaces (the BCRC will complete);

d. NM108—populate “46”; and

e. NM109—include 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. NM101—populate “85”;

b. NM102—populate “2”;

c. NM103—derived from A/B MAC (A or HH)’s internal provider file;

d. NM108—populate “XX”; and

e. NM109—populate 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. NM101—populate “85”;

b. NM102—populate “2”;

c. NM103—derive from the A/B MAC (A or HH)’s internal provider

file;

d. NM108—populate “XX”; and

e. NM109—derive NPI from Form Locator (FL) 56 of the Form CMS-1450

claim or applicable 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 segments as indicated below if the incoming claim is electronic.

a. NM101—populate “87”;

b. NM102—populate “2”; and

c. NM103—derived 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. NM101—populate “87”;

b. NM102—populate “2”; and

c. NM103—derived 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 claim’s format:

a. For REF01—populate “EI”; and

b. For REF02—derive from A/B MAC (A or HH)’s internal provider file.

10a. For the 2000A and 2310-PRV in association with incoming 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 PRV01—populate “BI”;

b. For PRV01—populate “PXC”; and

c. For PRV03—populate 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 PRV01—populate “BI”;

b. For PRV01—populate “PXC”; and

c. For PRV03—populate 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 NM1—Subscriber Name:

a. NM101—populate “IL”;

b. NM102—populate “1”;

c. NM103—derive from internal beneficiary eligibility file;

d. NM104—derive from internal beneficiary eligibility file;

e. NM105—derive from internal beneficiary eligibility file if available;

otherwise populate spaces;

f. NM108—populate “MI”; and

g. NM109—populate the beneficiary’s Medicare beneficiary identifier.

2010BA N3—Subscriber Address:

a. N301—derive from internal beneficiary eligibility file; and

b. N302—derive, as necessary, from internal beneficiary eligibility file;

otherwise populate spaces.

2010BA N4—Subscriber City/State/ZIP Code:

a. N401—derive from internal beneficiary eligibility file;

b. N402—derive from internal beneficiary eligibility file;

c. N403—derive from internal beneficiary eligibility file; and

d. N407—derive if available and applicable from internal beneficiary

eligibility file; otherwise populate spaces.

NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA

crossover claims when the individual data content for N401 (City) or N402 (State) or

N403 (Zip/Postal Code) cannot otherwise be derived.

15. The shared systems shall populate the 2330A (Other Subscriber) NM1, N3, and

N4 segments as follows:

2330A—NM1:

a NM101—populate “IL”;

b. NM102—populate “1”;

c. NM103—derive from internal beneficiary eligibility file;

d. NM104—derive from internal beneficiary eligibility file;

e. NM105—derive from internal beneficiary eligibility file if available;

otherwise populate spaces;

f. NM108—populate “MI”; and

g. NM109—populate the beneficiary’s Medicare beneficiary identifier.

2330A-N3:

a. N301—derive from internal beneficiary eligibility file; and

b. N302—derive, 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. N401—derive from internal beneficiary eligibility file; and

b. N402, N403, N404, N407—derive 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:

2010BB—NM1:

a. NM101—populate “PR”;

b. NM102—populate “2”;

c. NM103--populate spaces;

d. NM108—populate “PI”; and

e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the

BOI reply trailer 29).

2010BB-N3 & 2010BB-N4:

a. N301 & N302—populate spaces; and

b. For N401, N402, N403, N404, N407, populate spaces.

17. FISS shall not create 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

segment should be formatted as follows, with BCRC completing missing

information:

2nd and additional iterations of 2330B—NM1:

a. NM101—populate “PR”:

b. NM102—populate “2”;

c. NM103—populate spaces;

d. NM108—populate “PI”; and

e. NM109—populate 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 & N302—populate 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.

22a. FISS shall populate the required 2310-A (Attending Provider Name), 2310B

(Operating Physician Name), and 2310C (Other Operating Physician Name)

NM1 segments, with information derived from the incoming electronic claim.

FISS shall always populate the NM108 segment always indicating “XX” and

shall derive the NPI from the incoming claim.

22b. If the incoming claim is paper or DDE entered, FISS shall derive the attending,

operating, and other operating physician name from the Form CMS-1450 claim

or DDE entry, or as necessary from the A/B MAC (A or HH)’s internal provider

files. FISS shall always populate the NM108 segment with “XX” and shall

derive the NPI from the Form CMS-1450 claim or DDE entry screen.

23. When the incoming claim is paper, Form CMS-1450 or DDE entered, FISS shall

continue with all other mapping practices not otherwise addressed above when

creating the outbound “skinny” 837 COB flat file. [For example, FISS shall

continue to derive the discharge hour, admission date/hour, admission source

code, medical record number, principal diagnosis, admitting diagnosis code,

principal procedure information, occurrence codes, occurrence span codes,

value codes, and condition codes from the associated FL fields of the Form

CMS-1450 or from the DDE keyed information.]

24. FISS shall migrate the Line Item Control Number data from the Store and

Forward Repository (SFR) to the area of the ASC X12 837 COB flat file that

corresponds to loop 2400, REF02, where REF01=6R, as per the Implementation

Guide.

25. Upon implementation of the 5010 Errata changes, FISS shall take the following

action with respect to the creation of the field corresponding to 2300 CL101 on

the 837 COB flat file as a gap-fill or systems-fill value when necessary:

Map the value “9” (Information Not Available) to the field corresponding to

2300 CL101 on the ASC X12 837 COB flat file if the incoming claim is

received in a claim format other than the new, now current version, and the

CWF BOI reply trailer 29 indicator for “the new, now current version” returned

to the A/B MAC (A or HH) for the claim= “T” or “P.”

B. ASC X12 837 Professional COB Claim Mapping Rules

Effective with the testing and implementation of the Health Insurance Portability and

Accountability Act (HIPAA) ASC X12 837 professional new and now current version,

the Multi-Carrier System (MCS, the A/ B MAC (B) shared system) and the ViPS

Medicare System (VMS, the DME MAC shared system) shall observe the following

common business rules for mapping of the new and now current version COB

(professional) 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 (new and now current version)

in the field of the ASC X12 837 new version COB flat file that corresponds to

the ST03 segment.

3. The BHT02 (Beginning of the Hierarchical 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 Hierarchical 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-9—A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC or DME MAC

ID, or 5 bytes left justified, followed by 4 spaces);

Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);

Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should

increment for each ST-SE envelope);

Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010 claims); and

Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test; “P”—

production); and

Byte 23—Original versus Adjustment Claim Indicator (1 byte)-Valid Values are:

E—for reprocessed claims that formerly included an electronic

prescribing (e-RX) negative adjustment amount;

O—for original claims;

P— for Affordable Care Act or other congressional imperative mass

adjustments;

M—for non-Affordable Care Act mass adjustments tied to Medicare

Physician Fee Schedule (MPFS);

S—for mass adjustment claims—all others;

R—for RAC adjustment claims; and

A—for routine adjustment claims, not previously classified.

Additionally, as of April 7, 2014:

C – for CMS-directed mass adjustment action (use specified by CMS);

V—for void/cancel only claim

b. 23 bytes for COBA recovery claims as follows:

Bytes 1-9—A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC (B) or DME

MAC ID, left justified, or 5 bytes followed by 4 spaces);

Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);

Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should

increment for each ST-SE envelope);

Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010 claims); and

Byte 22—COBA recovery indicator (1 byte; indicator =R)

Byte 23—Original versus Adjustment Claim Indicator (1 byte)

(NOTE: See II.B.4.a directly above for valid values.)

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

the A/B MAC (B) or DME MAC receives multiple COBA IDs via the BOI reply

trailer (29), the shared system shall submit a separate ASC X12 837 transaction

for each COBA ID received. Since crossover trading partner information will be

unknown to the shared systems, the shared system shall format the following

fields as indicated:

a. NM101—populate “40”;

b. NM102—populate “2”;

c. NM103—populate spaces;

d. NM108—populate “46”; and

e. NM109—include COBA ID (5-digit COBA ID obtained from the BOI

reply trailer 29).

7a. For all 2000A, 2310B, and 2420A PRV (Billing Provider Specialty Information)

segments, the A/B MAC ( B) and DME MAC shared systems shall map the

taxonomy code values reported in PRV01 through PRV03 on the incoming

electronic claim to the corresponding fields within the ASC X12 837 COB flat

file. If the values reported for these loops on the incoming claim are incomplete

or syntactically incorrect, the shared system shall not create the loop and

associated segments.

7b. The A/B MAC (B) shared system shall continue the practice of only mapping

2420A-level PRV segments if the incoming electronic claim is multi-line, with

differing rendering physicians associated to each line. The A/B MAC ( B) shared

system shall not map a 2420A-level reported PRV segment if the incoming

electronic claim contains a single detail line.

8. The A/B MAC (B) and DME MAC shared systems shall derive information for

2010AA PER 03, PER04, PER05, and PER06 if such information is present and

syntactically complete within the A/B MAC (B) or DME MAC’s internal

provider files. If such information is unavailable or incomplete, the affected

shared systems shall not create the 2010AA PER loop on the ASC X12 837 new

version professional COB flat file.

9. The A/B MAC (B) and DME MAC shared systems shall derive all provider

specific information necessary to populate the NM1 and N3 and N4 segments of

such loops as 2010AA, 2010AB, and 2310B from each A/B MAC (B) or DME

MAC’s internal provider files. In addition, where a provider’s tax ID is required

within a secondary REF segment, the shared systems shall also derive this

information from each A/B MAC (B) or DME MAC’s internal provider files.

10a. For 2320 SBR01, in situations where there is only one (1) payer that is primary

to Medicare, VMS 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, the DME MAC shared system shall reflect the primary

payer as 2320 SBR01as “P”; the secondary payer as 2320 SBR01 = “S”; and, the

tertiary payer, Medicare, as 2320 SBR01 = “T.” MCS shall reflect all additional

supplemental payers as 2320 SBR01 = “U.”

10b. For 2000B SBR01 (element 1138), the shared system shall apply “P” when

Medicare is the primary payer and shall apply “U” for all other supplemental

payers after Medicare.

11. For additional 2000B requirements, the shared system shall take the following

actions:

a. SBR03—map spaces; and

b. SBR09—If the COBA ID returned via the BOI reply trailer (29)=70000-

79999, map “MC”; for all other COBA IDs, map “CI.”

12. The 2010BA loop denotes beneficiary subscriber information. There are two (2)

crossover scenarios to address: regular, eligibility file-based crossover, and

Medigap claim-based crossover.

(1) For regular eligibility file-based crossover (COBA ID=anything except 55000

through 59999), the shared system shall populate the NM1, N3, and N4 segments

as follows:

2010BA NM1—Subscriber Name:

a. NM101—populate “IL”;

b. NM102—populate “1”;

c. NM103—derive from internal beneficiary eligibility file;

d. NM104—derive from internal beneficiary eligibility file;

e. NM105—derive from internal beneficiary eligibility file if available;

otherwise populate spaces;

f. NM108—populate “MI”; and

g. NM109—populate the beneficiary’s Medicare beneficiary identifier.

2010BA N3—Subscriber Address:

a. N301—derive from internal beneficiary eligibility file; and

b. N302—derive, as necessary, from internal beneficiary eligibility file;

otherwise populate spaces.

2010BA N4—Subscriber City/State/ZIP Code:

a. N401—derive from internal beneficiary eligibility file;

b. N402—derive from internal beneficiary eligibility file;

c. N403—derive from internal beneficiary eligibility file; and

d. N407—derive if available and applicable from internal beneficiary

eligibility file; otherwise populate spaces.

NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA

crossover claims when the individual data content for N401 (City) or N402 (State) or

N403(Zip/Postal Code) cannot otherwise be derived.

(2) Medigap claim-based crossover (COBA ID=55000 through 59999 only), the

shared system shall populate the NM1, N3, and N4 segments as follows:

2010BA NM1—Subscriber Name:

a. NM101—populate “IL”;

b. NM102—populate “1”;

c. NM103—derive from internal beneficiary eligibility file;

d. NM104—derive from internal beneficiary eligibility file;

e. NM105—derive from internal beneficiary eligibility file if available;

otherwise populate spaces;

f. M108—populate “MI”; and

g. M109—populate beneficiary policy number as derived from Item 9-D of

Form CMS-1500 claim or 2330B NM109 of the incoming 837

professional claim. The shared system shall only populate the

beneficiary’s Medicare beneficiary identifier here if the policy number is

unavailable on the incoming claim.

2010BA N3—Subscriber Address:

a. N301—derive from internal beneficiary eligibility file;

b. N302—derive, as necessary, from internal beneficiary eligibility file;

otherwise populate spaces.

2010BA N4—Subscriber City/State/ZIP Code:

a. N401—derive from internal beneficiary eligibility file;

b N402—derive from internal beneficiary eligibility file;

c. N403—derive from internal beneficiary eligibility file; and

d. N407—derive, if available, from internal beneficiary eligibility file;

otherwise populate spaces.

NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA

crossover claims when the individual data content for N401 (City) or N402 (State) or

N403 (Zip/Postal Code) cannot otherwise be derived.

13. The shared system shall populate the 2330A (Other Subscriber) NM1, N3, and N4

segments as follows:

2330A—NM1:

a. NM101—populate “IL”;

b. NM102—populate “1”;

c. NM103—derive from internal beneficiary eligibility file;

d. NM104—derive from internal beneficiary eligibility file;

e. NM105—derive from internal beneficiary eligibility file if available;

otherwise populate spaces;

f. NM108—populate “MI”; and

g. NM109—populate the beneficiary’s Medicare beneficiary identifier.

2330A-N3:

a. N301—derive from internal beneficiary eligibility file; and

b. N302—derive, as necessary, from internal beneficiary eligibility file as

necessary; otherwise populate spaces.

2330A-N4:

Upon implementation of the 5010 Errata, the A/B MAC (B) and DME MAC

shared systems 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 systems shall not create the N4 segment tied to loop

2330A within the ASC X12 837 COB flat file.

a. N401—derive from internal beneficiary eligibility file; and

b. N402, N403, N404, N407—derive from internal beneficiary eligibility file

if available and applicable; otherwise populate spaces.

14. 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 shared systems, the shared system shall format the NM1, N3, and

N4 segments as follows, with the BCRC completing any missing information:

2010BB—NM1:

a. NM101—populate “PR”;

b. NM102—populate “2”;

c. NM103—populate spaces;

d. NM108—populate “PI”; and

e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the

BOI reply trailer 29).

2010BB-N3 & 2010BB-N4:

a. N301 & N302—populate spaces; and

b. For N401, N402, N403, N404, N407, populate spaces.

15. The shared system shall not create the 2000C or the 2010CA loops within the

ASC X12 837 new version professional COB flat file.

16. If the shared system 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 ASC X12 837 new version COB

professional flat file.

17. The 2330B loop denotes other payers for the claim following Medicare. There

will always be one (1) 2330B that denotes Medicare as a payer, with the shared

system completing all required information for NM101, NM102, NM103,

NM108, NM109, as well as the N3 and N4 segments.

18. For additional 2330B loop iterations relating to COB, if the A/B MAC (B) or

DME 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 shared system shall format the NM1 segment as follows, with the BCRC

completing missing information:

2nd and additional iterations of 2330B—NM1:

a. NM101—populate “PR”;

b. NM102—populate “2”;

c. NM103—populate spaces;

d. NM108—populate “PI”; and

e. NM109—populate 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 & N302—populate spaces; and

b. For N401, N402, N403, N404, N407, populate spaces.

19. The shared system shall always send at least one (1) complete iteration of 2320,

2330A, and 2330B on all ASC X12 837 COB flat files.

20. For 2300 REF (4081-Mandatory Crossover Indicator), the shared system shall

take the action indicated below in accordance with the applicable scenario:

a. REF01, always map “F5”;

b. REF02, map “Y” if the COBA ID returned via the BOI reply trailer

(29)=55000 through 55999 (Medigap claim-based crossover); and

c. REF02, map “N” if the COBA ID returned via the BOI reply trailer (29)

=anything except for 55000 through 55999 (regular crossover).

Additional Mapping Requirements When Incoming Claim is Paper/Hard-Copy

**IMPORTANT: The shared system shall create an outbound new version

“skinny” claim, as derived from paper/hard copy claim input, in

the same manner that it now does in creating the current in-use

(prior to new version) claim, unless otherwise specified above or

below.

1. The shared system shall always map NDC codes keyed from hard-copy claims to

the field that corresponds to 2410 LIN03 on the ASC X12 837 new version COB

professional flat file. In addition, the shared system shall auto-plug the appropriate

qualifier that designated NDC within the field that corresponds to 2410 LIN02.

2. If the incoming paper claim contains an NPI in block 32 of the Form CMS-1500,

the shared system shall continue to utilize this keyed value for purposes of deriving

the information necessary to populate all required segments associated with 2310C

(Service Facility Name). The shared system shall continue to not create the 2310C

loop if block 32 on the incoming paper claim is blank.

3. If the incoming claim is paper and does not contain information necessary to derive

2410 CTP5-1 (in association with Part B drugs), the shared system shall auto-plug

the value “F2.”

III. Gap-Filling Requirements for ASC X12 837 New Version COB Files (Effective

July 2012)

A. ASC X12 837 Institutional COB Claims

1. For all instances of the N403 segment, where created, FISS shall ensure that it creates

a 5-byte base ZIP code and additional 4-byte component for the COB flat file when

required.

2. FISS shall universally gap-fill or systems-fill required individual address elements,

when not otherwise obtainable, for Subscriber-related loops as follows:

N401 (City Name) = Cityville;

N402 (State or Province Code) = MD; and

N403 (Postal Zone/ZIP Code) = 96941.

NOTE: The above is particularly applicable in the creation of the indicated

segments within the 2010BA loop when the needed data are individually not

otherwise unavailable.

3. FISS shall gap-fill the +4 ZIP code component with 9998 when the actual +4 ZIP

code component is unavailable when creating the N403 in association with loops

2010AA (Billing Provider) and 2310E (Service Facility). (NOTE: The full 9-byte

ZIP code is required only for the N403 segment of the indicated loops.)

4. FISS shall never input “0000” as a gap-fill or system-fill +4 ZIP code in association

with any of the N403 segments.

5a. If the shared system has valid city, state, and 5-byte ZIP code information available, it

shall only gap-fill or system-fill the +4 ZIP code component, where required, with

“9998” when creating outbound ASC X12 837 COB claim files.

5b. The shared system shall continue to send full ZIP code content (9-bytes) on outbound

ASC X12 837 COB claim files, if available, for creation of situational N403

segments.

6. When the shared system determines that it has data within its internal provider file to

populate 2010AA PER 04, it shall only move that information to the corresponding

flat file field if the available data are complete. If the available data are incomplete

(i.e., fewer than 10 digits for telephone number), the shared system shall not attempt

to gap-fill the missing digits. The shared system shall also not create that PER

segment.

7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME

MAC’s internal beneficiary eligibility record contains blank or incomplete line-1

street address information, FISS shall apply “Xs” to satisfy the minimum length

requirements of the N301 segments.

8. If the incoming claim is paper Form CMS-1450 or DDE-entered and the dosage

information necessary to populate 2410 CTP05-1 is not available, FISS shall always

default to the value of “F2.”

9. If the incoming claim is paper or electronic, FISS shall map “non-specific procedure

code” within the ASC X12 837 new version COB flat file field that corresponds to

loop 2400 SV202-7 (non-specific composite medical procedure description) if a non-specific procedure code description is required, as per the Implementation Guide, and

the associated procedure code is defined as “not otherwise classified.” (See the

following link for the latest listing of not otherwise classified procedure codes:

https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha-Numeric-

HCPCS.html?DLSort=0&DLEntries=10&DLPage=1&DLSortDir=descending&DLF

ilter=NOC

10. FISS shall not attempt to gap-fill or systems-fill the N4 segment (now situational)

within the field corresponding to loop 2330B on the ASC X12 837 new version

COB flat file. In addition, if information needed to create the N4 segment is

available but is incomplete, FISS shall not create the loop 2330B N4 segment.

11. FISS shall not attempt to gap-fill or systems-fill any of the composite SVD03

elements within loop 2430.

B. ASC X12 837 Professional COB Claims

1. For all instances of the N403 segment, where created, the A/B MAC ( B) and DME

MAC shared systems shall ensure that it creates a 5-byte base ZIP code and

additional 4-byte component for the COB flat file when required.

2. The A/B MAC (B) and DME MAC shared systems shall universally gap-fill or

system-fill required individual address elements, when not otherwise obtainable, for

all Subscriber-related loops as follows:

N401 (City Name) = Cityville;

N402 (State or Province Code) = MD; and

N403 (Postal Zone/ZIP Code) = 96941.

NOTE: The above is particularly applicable in the creation of the indicated

segments within the 2010BA loop when the needed data are individually otherwise

not unavailable.

3. The A/B MAC (B) and DME MAC shared systems shall gap-fill the +4 ZIP code

component with 9998 when the actual +4 ZIP code component is unavailable when

creating the N403 in association with loops 2010AA (Billing Provider), 2310C

(Service Facility—claim level), and 2420C (Service Facility—service line level).

(NOTE: The full 9-byte ZIP code is required only for the N403 segment of the

indicated loops.)

4. The A/B MAC (B) and DME MAC shared systems shall never input “0000” as a

gap-fill or system-fill +4 ZIP code in association with any of the N403 segments.

5a. If the A/B MAC (B) and DME MAC shared systems have valid city, state, and 5-byte ZIP code information available, they shall only gap-fill or system-fill the +4

ZIP code component, where required, with “9998” when creating outbound ASC

X12 837 COB claim files.

5b. The A/B MAC (B) and DME MAC shared system shall continue to send full ZIP

code content (9-bytes) on outbound ASC X12 837 COB claim files, if available, for

creation of situational N403segments

6. When the shared system determines that it has data within its internal provider file to

populate 2010AA PER 04, it shall only move that information to the corresponding

flat file field if the available data are complete. If the available data are incomplete

(i.e., fewer than 10 digits for telephone number), the shared system shall not attempt

to gap-fill the equivalent field on the new version COB flat file.

7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME

MAC’s internal beneficiary eligibility record contains blank or incomplete line-1

street address information, the shared system shall apply “Xs” to satisfy the

minimum length requirements of the N301 segments.

8a. In association with paper-submitted Part B ambulance claims, the A/B MAC (B)

shared system shall apply gap-filling to the N3 and N4 portions of loop 2310E and

2310F as follows for the segments indicated:

For N301: The A/B MAC (B) shared system shall map “Xs” to the minimum

standard required for the field.

For N401—N403: The A/B MAC (B) shared system shall undertake the following

actions:

N401 (City)—populate “Cityville”;

N402 (State Code)—populate “MD”; and

N403 (Postal Zone/ZIP Code)—populate “96941.”

8b. In addition, the A/B MAC (B) shared system shall gap-fill the required +4

component of ZIP code (N403 segment) with 9998 only in association with loops

2010AA, 2310C, and 2420C.

9. The shared system shall map “UN” in the ASC X12 837 new version COB flat file

field that corresponds to loop 2410 (CTP) and segment CPT04 only when the 2410

(CTP) CTP04 segment is either blank or contains a non-valid value.

10. The shared system shall apply the gap-fill value “X” to the field corresponding to

loop 2430 (SVD) and segment SVD03-2 in situations where the value on the

incoming claim is either missing or non-valid.

11. The A/B MAC (B) shared system shall discontinue the process of gap-filling

diagnosis code information within loop 2300 HI in association with ambulance

claims that ambulance suppliers file to Medicare on paper.

12a. Following adjudication of both electronic and paper billed claims, the shared

system shall discontinue the practice of applying gap-fill values of all “9s” within

the ASC X12 837 new version COB flat file field that corresponds to 2410 LIN03 if

the incoming claim contains an incomplete or non-valid national drug code (NDC).

If an incoming paper claim contains a syntactically non-valid NDC code that the

A/B MAC (B) or DME MAC subsequently keys, the shared system shall not

attempt to gap-fill the field that corresponds to 2410 LIN03 on the ASC X12 837

new version COB flat file.

12b. The DME MAC shared system shall gap-fill the loop 2430 (SVD) SVD03-2

segment with “S5000” or “S5001,” as appropriate, in situations where the incoming

claim contains an NDC within the 2410 LIN02 that does not correspond to a

HCPCS on the NDC/HCPCS crosswalk.

13. If the incoming claim is paper and A/B MAC or DME MAC’s internal provider file

contains incomplete information necessary to populate the 2310C loop (in cases

where required), the shared system shall gap-fill all required segments with “Xs.”

NOTE: The shared system shall discontinue the practice of mapping “submitted

but not forwarded” as a gap-fill convention in this situation for segments where

information is required.

14. If the incoming claim is paper or electronic, the shared system shall map “non-specific procedure code” within the ASC X12 837 COB flat file field that

corresponds to loop 2400 SV202-7 (non-specific composite medical procedure

description) if a non-specific procedure code description is required, as per the

Implementation Guide, and the associated procedure code is defined as “not

otherwise classified.” (See the following link for the latest listing of not otherwise

classified procedure codes:

https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha-Numeric-

HCPCS.html?DLSort=0&DLEntries=10&DLPage=1&DLSortDir=descending&DL

Filter=NOC

15. The A/B MAC (B) shared system shall utilize the claim’s earliest service date to

satisfy the requirement for 2300 DTP03 (date of admission), where required, in

association with claims whose place of service code is 21, 51, or 61.

16. The A/B MAC (B) shared system shall populate 99 as a gap-fill/default value for

loop 2300 (CLM) segment CLM05-1 (Facility Type Code) within the

corresponding field of the ASC X12 837 new version COB flat file.

17. For ambulance claims, the A/B MAC (B) shared system shall map LB in the ASC

X12 837 new version COB flat file field the corresponds to 2400 CR101 if that field

would otherwise contain spaces where there is a value (weight) present in 2400

CR102.

18. Also, for ambulance claims, the A/B MAC (B) shared system shall produce spaces

in the field that corresponds to loop 2400 CR101 when loop 2400 CR102 on the

incoming claim is blank.

19. All shared systems shall not attempt to gap-fill or systems-fill the N4 segment (now

situational) within the field corresponding to loop 2330B on the ASC X12 837 COB

flat file. In addition, if information needed to create the N4 segment is available but

is incomplete, the shared systems shall not create the loop 2330B N4 segment.

IV. Other ASC X12 837 New Version COB Requirements

A. Complementary Credits

Upon receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) that contains a “P”

ASC X12 837 indicator, the shared systems shall ensure that their affiliate A/B MACs

and DME MACs are able to: 1) book complementary credits for the affected claim; and

2) transmit the “production” claim to the BCRC after it has finalized on the A/B MAC or

DME MAC’s payment floor.

Following receipt of a BOI reply trailer (29) that contains a “T” ASC X12 837 indicator,

as applicable, the shared systems shall ensure that their affiliate MACs: 1) do not

anticipate receipt of complementary credits for that version of the claim; and 2) transmit

the “test” claim to the BCRC after it has finalized on the contractor’s payment floor.

All shared systems shall, in addition, not expect complementary credits in association

with their affiliated A/B MAC or DME MAC’s receipt of a CWF BOI reply trailer (29)

that contains an “N” new version indicator.

B. BCRC Business-Level Editing of Incoming New Version COB Flat Files

With the implementation of the new version claim standards, the BCRC will apply

business level edits to ensure that incoming claims possess the structure necessary for

successful translation into the HIPAA ASC X12 837 new version claim formats. See

§70.6.1.1 of this chapter for charts that define the “111” level errors that the BCRC will

return to the A/B MACs or DME MACs when their incoming ASC X12 837 COB flat

files cannot be utilized to build compliant outbound ASC X12 837 claim transactions.