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

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.

Background – Medicare Claims Crossover Process—General

Through the Benefits Coordination & Recovery Center (BCRC), Medicare transmits outbound 837

Coordination of Benefit (COB) and Medigap claims to COB trading partners and Medigap plans,

collectively termed “trading partners,” on a post-adjudicative basis. This type of transaction, originating at

individual A/B MACs and DME MACs following their claims adjudication activities, includes incoming

claim data, as modified during adjudication if applicable, as well as payment data. All A/B MACs and

DME MACs are required to accept all ASC X12 837 segments and data elements permitted by the in-force

applicable guides on an initial ASC X12 837 professional or institutional claim from a provider, but they are

not required to use every segment or data element for Medicare adjudication. Segments and data elements

determined to be extraneous for Medicare claims adjudication shall, however, be retained by the A/B MACs

(Part B) and DME MACs within its store-and-forward repository (SFR). Incoming claims data shall be

subjected to standard syntax and applicable implementation guide (IG) edits prior to being deposited in the

SFR to assure non-compliant data will not be forwarded on to another payer as part of the Medicare

crossover process. SFR data shall be re-associated with those data elements used in Medicare claim

adjudication, as well as with payment data, to create an ASC X12 837 IG-compliant outbound

COB/Medigap transaction. The shared systems shall always retain the data in the SFR for a minimum of 6

months.

The ASC X12 837 institutional and professional implementation guides require that claims submitted for

secondary payment contain standard claim adjustment reason codes (CARCs) to explain adjudicative

decisions made by the primary payer. For a secondary claim to be valid, the amount paid by the primary

payer plus the amounts adjusted by the primary payer shall equal the billed amount for the services in the

claim. A tertiary payer to which Medicare may forward a claim may well need all data and adjustment

codes Medicare receives on a claim. A tertiary payer could reject a claim forwarded by Medicare if the

adjustment and payment data from the primary payer or from Medicare did not balance against the billed

amounts for the services and the claim. As a result, shared systems shall reject inbound Medicare Secondary

Payer (MSP) claims if the paid and adjusted amounts do not equal the billed amounts and if the claims lack

standard CARCs to identify adjustments to the total amount billed.

As a rule, the shared system maintainers shall populate an outbound COB/Medigap file as an ASC X12 837

flat file with the Employer Identification Number (EIN)/Tax ID or SSN (for a sole practitioner) present in

the provider’s file, unless otherwise specified within §70.6.5 or §70.6.6 of this chapter. With the adoption of

the National Provider Identifier (NPI), the shared system shall report qualifier XX in NM108 and the NPI

value in NM109. The shared system shall report the provider’s EIN/TAX ID within the REF segment of the

billing provider loop, as appropriate. In addition, unless otherwise stated within §70.6.5 or §70.6.6 of this

chapter, the shared systems shall populate the provider loops on outbound ASC X12 837 claims with the

provider’s first name, last name, middle initial, address, city, state and zip code as contained in the Medicare

provider files, the information for which is derived from the Provider Enrollment Chain and Ownership

System (PECOS).

Background—Specific COBA Crossover Process

The CMS has streamlined the claims crossover process to better serve its customers. Under the consolidated

claims crossover process, trading partners execute national agreements called Coordination of Benefits

Agreements (COBAs) with CMS’s BCRC. Through the COBA process, each COBA trading partner will

send one national eligibility file that includes eligibility information for each Medicare beneficiary that it

insures to the BCRC. The BCRC will transmit the beneficiary eligibility file(s) to the Common Working

File (CWF) via the HUBO maintenance transaction. The transaction is also termed the “Beneficiary Other

Insurance (BOI)” auxiliary file. (See Pub.100-04, chapter 27, §80.4 for more details about the contents of

the BOI auxiliary file.)

During August 2003, the CMS modified CWF to accept both the HUBO (BOI) transaction on a regular basis

and COBA Insurance File (COIF) as a weekly file replacement. Upon reading both the BOI and the COIF,

CWF applies each COBA trading partner’s claims selection criteria against processed claims with service

dates that fall between the effective and termination date of one or more BOI records.

Upon receipt of a BOI reply trailer (29) that contains (a) COBA ID (s) and other crossover information

required on the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 835 Electronic

Remittance Advice (ERA), all A/B MACs and DME MACs shall send processed claims via an ASC X12 837

COB flat file or National Council for Prescription Drug Programs (NCPDP) file to the BCRC. The BCRC, in

turn, will cross the claims to the COBA trading partner in the HIPAA ASC X12 837 or NCPDP formats,

following its validation that the incoming Medicare claims are formatted correctly and pass HIPAA or

NCPDP compliance editing.

In addition, CMS shall arrange for the invoicing of COBA trading partners for crossover fees.

For more information regarding the COBA Medigap claim-based crossover process, which was enacted on

October 1, 2007, consult §70.6.4 of this chapter.

I. A/B MAC (Part A, Part B, or Part HHH) or DME MAC Actions Relating to CWF Claims

Crossover Exclusion Logic

A. Determination of Beneficiary Liability for Claims with Denied Services

Effective with the January 2005 release, the A/B MAC (Part B) and DME MAC shared systems shall include

an indicator “L” (beneficiary is liable for the denied service[s]) or “N” (beneficiary is not liable for the denied

service[s]) in an available field on the HUBC and HUDC queries to CWF for claims on which all line items

are denied. The liability indicators (L or N) shall be reflected at the header or claim level rather than at the

line level.

For purposes of applying the liability indicator L or N at the header/claim level and, in turn, including such

indicators in the HUBC or HUDC query to CWF, the A/B MACs (Part B) and DME MAC shared systems

shall follow these business rules:

• The L or N indicators are not applied at the header/claim level if any service on the claim is payable

by Medicare;

• The “L” indicator is applied at the header/claim level if the beneficiary is liable for any of the denied

services on a fully denied claim; and

• The “N” indicator is applied at the header/claim level if the beneficiary is not liable for all of the

denied services on a fully denied claim.

Effective with October 2007, the CWF maintainer shall create a 1-byte beneficiary liability indicator field

within the header of its HUIP, HUOP, HUHH, and HUHC Part A claims transactions (valid values for the

field=“L,” “N,” or space).

As A/B MACs (Part A) and A/B MACs (Part HHH) adjudicate claims and determine that the beneficiary

has payment liability for any part of the fully denied services or service lines, they shall set an “L” indicator

within the newly created beneficiary liability field in the header of their HUIP, HUOP, HUHH, and HUHC

claims that they transmit to CWF. In addition, as A/B MACs (Part A) and A/B MACs (Part HHH)

adjudicate claims and determine that the beneficiary has no payment liability for any of the fully denied

services or service lines - that is, the provider must absorb all costs for the fully denied claims - they shall

include an “N” beneficiary indicator within the designated field in the header of their HUIP, HUOP, HUHH,

and HUHC claims that they transmit to CWF. NOTE: A/B MACs (Part A) and A/B MACs (Part HHH)

shall not set the “L” or “N” indicator on partially denied/partially paid claims.

Upon receipt of an HUIP, HUOP, HUHH, or HUHC claim that contains an “L” or “N” beneficiary liability

indicator, CWF shall read the COBA Insurance File (COIF) to determine whether the COBA trading partner

wishes to receive “original” fully denied claims with beneficiary liability (crossover indicator “G”) or

without beneficiary liability (crossover indicator “F”) or “adjustment” fully denied claims with beneficiary

liability (crossover indicator “U”) or without beneficiary liability (crossover indicator “T”).

If CWF determines that the COBA trading partner wishes to exclude the claim, as per the COIF, it shall

suppress the claim from the crossover process.

CWF shall post the appropriate crossover disposition indicator in association with the adjudicated claim on

the HIMR detailed history screen (see §80.5 of this chapter).

In addition, the CWF maintainer shall create and display the new 1-byte beneficiary liability indicator field

within the HIMR detailed history screens (INPL, OUTL, HHAL, and HOSL), to illustrate the indicator (“L”

or “N”) that appeared on the incoming HUIP, HUOP, HUHH, or HUHC claim transaction.

CWF Editing for Incorrect Values

If an A/B MAC (Part A) or A/B MAC (Part HHH) sends values other than “L,” “N,” or space in the newly

defined beneficiary liability field in the header of its HUIP, HUOP, HUHH, or HUHC claim, CWF shall

reject the claim back to the A/B MAC for correction. Following receipt of the CWF rejection, the A/B

MAC (Part A) and A/B MAC (Part HHH) shall change the incorrect value placed within the beneficiary

liability field and retransmit the claim to CWF.

B. Developing a Capability to Treat Entry Code “5” and Action Code “3” Claims As Recycled

“Original” Claims For Crossover Purposes

Effective with July 2007, in instances when CWF returns an error code 5600 to an A/B MAC and DME

MAC, thereby causing it to reset the claim’s entry code to “5” and action code to “3,” the MAC shall set a

newly developed “N”(non-adjustment) claim indicator (“treat as an original claim for crossover purposes”)

in the header of the HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claim in the newly defined field

before retransmitting the claim to CWF. The A/B MAC and DME MAC shared system shall then resend the

claim to CWF.

Upon receipt of a claim that contains entry code “5” or action code “3” with a non-adjustment claim header

value of “N,” the CWF shall treat the claim as if it were an “original” claim (i.e., as entry code “1” or action

code “1”) for crossover inclusion or exclusion determinations. If CWF subsequently determines that the

claim meets all other inclusion criteria, it shall mark the claim with an “A” (“claim was selected to be

crossed over”) crossover disposition indicator.

Following receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) for the recycled claim, the A/B

MACs’ and DME MACs’ shared systems shall ensure that, as part of their ASC X12 837 flat file creation

processes, they populate the 2300 loop CLM05-3 (Claim Frequency Type Code) segment with a value of

“1” (original). In addition, the A/B MACs’ and DME MACs’ shared systems shall ensure that, as part of

their ASC X12 837 flat file creation process, they do not create a corresponding 2330 loop REF*T4*Y

segment, which typically signifies “adjustment.”

C. Developing a Capability to Treat Claims with Non-Adjustment Entry or Action Codes as

Adjustment Claims For Crossover Purposes

Effective with July 2007, in instances where A/B MACs and DME MACs must send adjustment claims to

CWF as entry code “1” or as action code “1” (situations where CWF has rejected the claim with edit 6010),

they shall set an “A” indicator in a newly defined field within the header of the HUBC, HUDC, HUIP,

HUOP, HUHH, or HUHC claim.

If A/B MACs and DME MACs send a value other than “A” or spaces within the newly designated header

field within their HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims, CWF shall apply an edit to

reject the claim back to the MAC. Upon receipt of the CWF rejection edit, the MACs’ systems shall correct

the invalid value and retransmit the claim to CWF for verification and validation.

Upon receipt of a claim that contains entry code “1” or action code “1” with a header value of “A,” the CWF

shall take the following actions:

• Verify that, as per the COIF, the COBA trading partner wishes to exclude either adjustments,

monetary adjustments, non-monetary, or both; and

• Suppress the claim if the COBA trading partner wishes to exclude either adjustments, monetary

adjustments, non-monetary, or both.

NOTE: The expectation is that such claims do not represent mass adjustments tied to the MPFS or mass

adjustments-other.

If A/ B MACs and DME MACs receive a BOI reply trailer (29) on a claim that had an “A” indicator set in

its header, the A/B MACs’ or DME MACs’ systems shall ensure that, as part of their ASC X12 837 flat file

creation processes, they populate the 2300 loop CLM05-3 (“Claim Frequency Type Code”) segment with a

value that designates “adjustment” rather than “original” to match the 2330B loop REF*T4*Y that they

create to designate “adjustment claim.”

If an A/B MAC’s or DME MAC’s shared system does not presently create a loop 2330B REF*T4*Y to

designate adjustments, it shall not make a change to do so as part of this instruction.

Correcting Invalid Claim Header Values Sent to CWF

If A/B MACs and DME MACs send a value other than “A,” “N,” or spaces within the newly designated

header field within their HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims, CWF shall apply an edit

to reject the claim back to the A/B MAC or DME MAC. Upon receipt of the CWF rejection edit, the A/B

MACs’ or DME MACs’ systems shall correct the invalid value and retransmit the claim to CWF for

verification and validation.

D. CWF Identification of National Council for Prescription Drug Claims

Currently, the DME MAC shared system is able to identify, through the use of an internal indicator, whether a

submitted claim is in the National Council for Prescription Drug Programs (NCPDP) format. Effective with

January 2005, the DME MAC shared system shall pass an indicator “P” to CWF in an available field on the

HUDC query when the claim is in the NCPDP format. The indicator “P” should be included in a field on the

HUDC that is separate from the fields used to indicate whether a beneficiary is liable for all services that are

completely denied on his/her claim.

The CWF shall read the new indicators passed via the HUBC or HUDC queries for purposes of excluding 100

percent denied claims with or without beneficiary liability and NCPDP claims. After applying the claims

selection options, CWF will return a BOI reply trailer (29) to the A/B MAC or DME MAC only in those

instances when the COBA trading partner expects to receive a Medicare processed claim from the BCRC.

Effective with July 2007, CWF shall reject claims back to DME MACs if their HUDC claim contains a value

other than “P” in the established field used to identify NCPDP claims.

E. CWF Identification and Auto-Exclusion of ASC X12 837 Professional Claims That Contain Only

Physician Quality Reporting Initiative (PQRI) Codes

Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUBC claim

transmission for a 1-byte PQRI indicator (valid values=Q or space).

In addition, CWF shall create a 2-byte field on page 2 of the HIMR claim detail in association with the new

category “COBA Bypass” for the value “BQ,” which shall designate that CWF auto-excluded the claim

because it contained only PQRI codes (see §80.5 of this chapter for more details regarding the bypass

indicator).

Prior to transmitting the claim to CWF for normal processing, the A/B MAC (Part B) shared system shall

input the value “Q” in the newly defined PQRI field in the header of the HUBC when all service lines on a

claim contain PQRI (status M) codes.

Upon receipt of a claim that contains a “Q” in the newly defined PQRI field (which signifies that the claim

contains only PQRI codes on all service detail lines, CWF shall auto-exclude the claim from the national

COBA eligibility file-based and Medigap claim-based crossover processes. Following exclusion of the

claim, CWF shall populate the value “BQ” in association with the newly developed “COBA Bypass” field

on page 2 of the HIMR A/B MAC (Part B) and DME MAC claim detail screens.

Prior to October 6, 2008, all A/B MACs and DME MACs shall update any of their provider customer

service materials geared towards crossover claims related inquiries to reflect the newly developed “BQ” bypass value, which designates that CWF auto-excluded the claim because it only contained PQRI codes.

The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to

reflect the new “BQ” code.

F. CWF Identification and Exclusion of Claims Containing Placeholder National Provider Identifiers

(NPIs)

Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUIP, HUOP,

HUHH, HUHC, HUBC, and HUDC claims transactions for a new 1-byte “NPI-Placeholder” field

(acceptable values=Y or space).

In addition, the CWF maintainer shall create space within page two (2) of the HIMR detail of the claim

screen for 1) a new category “COBA Bypass”; and 2) a 2-byte field for the indicator “BN.” (See Pub. 100-

04, chapter 27, §80.5 for more details regarding the “BN” bypass indicator.)

NOTE: With the implementation of the October 2008 release, the CWF maintainer shall remove all current

logic for placeholder provider values with the implementation of this new solution for identifying claims

that contain placeholder provider values.

As A/B MACs and DME MACs adjudicate non VA MRA claims that fall within any of the NPI placeholder

requirements, their shared system shall take the following combined actions:

1) Input a “Y” value in the newly created “NPI Placeholder” field on the HUIP, HUOP, HUHH,

HUHC, HUBC, or HUDC claim transaction if a placeholder value exists on or is created

anywhere within the SSM claim record. NOTE: The A/B MAC and DME MAC shared systems

shall include spaces within the “NPI Placeholder” field when the claim does not contain a

placeholder NPI value; and

2) Transmit the claim to CWF, as per normal requirements.

Upon receipt of claims where the NPI Placeholder field contains the value “Y,” CWF shall auto-exclude the

claim from the national COBA crossover process. In addition, CWF shall populate the value “BN” in

association with the newly developed “COBA Bypass” field on page 2 of the HIMR Part B and DME MAC

claim detail screen and on page 3 of the HIMR intermediary claim detail screen. (See Pub.100-04, chapter

27, §80.4 for more details.)

Prior to October 6, 2008, all A/B MACs and DME MACs shall update any of their provider customer service

materials geared towards crossover claims related inquiries to reflect the newly developed “BN” by-pass

value, which designates that CWF auto-excluded the claim because it contained a placeholder provider value.

The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to

reflect the new “BN” code.

G. New CWF Requirements for Other Federal Payers

Effective with October 3, 2011, the CWF maintainer shall expand its logic for “Other Insurance,” which is

COIF element 176, to include TRICARE for Life (COBA ID 60000-69999) and CHAMPVA (COBA ID

80214), along with State Medicaid Agencies (70000-79999), as entities eligible for this exclusion.

Through these changes, if either TRICARE for Life or CHAMPVA wishes to invoke the “Other Insurance”

exclusion, and if element 176 is marked on the COIF for these entities, CWF shall suppress claims from the

national COBA crossover process if it determines that the beneficiary has active additional supplemental

coverage.

As part of this revised “Other Insurance” logic for TRICARE and CHAMPVA, CWF shall interpret

“additional supplemental coverage” as including entities whose COBA identifiers fall in any of the

following ranges:

00001-29999 (Supplemental);

30000-54999 (Medigap eligibility-based);

80000-80213 (Other Insurer); and

80215-88999 (Other Insurer).

The “Other Insurance” logic for State Medicaid Agencies includes all of the following COBA ID ranges:

00001-29999 (Supplemental);

30000-54999 (Medigap eligibility-based);

60000-69999 (TRICARE);

80000-80213 (Other Insurance)

80214 (CHAMPVA)

80215-88999 (Other Insurer).

NOTE: As of October 3, 2011, CWF shall now omit COBA ID range 89000-89999 as part of its Other

Insurance logic for State Medicaid Agencies.

CWF shall mark claims that it excludes due to “Other Insurance” with crossover disposition indicator “M”

when storing them within the CWF claims history screens. (See §80.5 of chapter 27 for additional

information concerning this indicator.)

II. A/B MAC and DME MAC Actions Relating to CWF Claims Crossover Inclusion or

Inclusion/Exclusion Logic

A. Inclusion of Two Categories of Mass Adjustment Claims for Crossover Purposes

All A/ B MACs and DME MACs shall continue to identify mass adjustment claims-MPFS and mass

adjustment claims—other by including an “M” (mass adjustment claims—MPFS) or “O” (mass adjustment

claims—other) within the header of the HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claim

transactions, as specified in Pub.100-04, chapter 27, §80.6. (Refer to Pub.100-04, chapter 27, §80.8 for CWF

specific requirements relating to the unique inclusion of mass adjustment claims for crossover purposes.)

Effective January 5, 2009, the BCRC, at CMS’s direction, modified the COIF to allow for the unique

inclusion of mass adjustment claims—MPFS updates and mass adjustment claims—other. The CWF

maintainer shall 1) create these new fields, along with accompanying 1-byte file displacement, within its

version of the COIF; and 2) accept and process these new fields when the BCRC transmits them as part of

its regular COIF updates.

Upon receipt of a HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim transaction that contains an “M”

or “O” mass adjustment indicator, CWF shall undertake all additional actions with respect to determination

as to whether the claim should be included or excluded for crossover purposes as specified in chapter 27,

§80.8.

A/B MAC and DME MAC Flat File Requirements

Before the A/B MAC and DME MAC shared systems send “mass adjustment claims—MPFS” to the BCRC

via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that

correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file only if there

was not a pre-existing 2300 NTE segment on the incoming Medicare claim:

1) Populate “ADD” in the field that corresponds to NTE01; and

2) Populate “MP,” utilizing bytes 01 through 02, in the field that corresponds to NTE02.

Before the A/B MAC and DME MAC shared systems send “mass adjustment claims—other” to the BCRC

via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that

correspond to the loop 2300 NTE01 and NTE02 segments on the 837 COB flat file only if there was not a

pre-existing 2300 NTE segment on the incoming Medicare claim:

1) Populate “ADD” in the field that corresponds to NTE01; and

2) Populate “MO,” utilizing bytes 01 through 02, in the field that corresponds to NTE02.

B. Inclusion and Exclusion of Recovery Audit Contractor (RAC)-Initiated Adjustment Claims

Effective January 5, 2009, at CMS’s direction, the BCRC modified the COIF to allow for the unique inclusion

and exclusion of RAC-initiated adjustment claims. The CWF maintainer shall 1) create these new fields,

along with accompanying 1-byte file dis-placement, within its version of the COIF; and 2) accept and process

these new fields when the BCRC transmits them as part of its regular COIF updates. In addition, the CWF

maintainer shall create a 1-byte RAC adjustment value in the header of its HUIP, HUOP, HUHH, HUHC,

HUBC, and HUDC claims transactions (valid values=“R” or spaces).

Through this instruction, all A/B MAC and DME MAC shared systems shall develop a method for uniquely

identifying all varieties of RAC-requested adjustments, which occur as the result of post-payment review

activities.

NOTE: Currently, fewer than five (5) MACs process RAC adjustments.

Prior to sending its processed 11X and 12X type of bill RAC-initiated adjustment transactions to CWF for

normal verification and validation, the A/B MAC (Part A) and A/B MAC (Part HHH) shared system shall

input the “R” indicator in the newly defined header field of the HUIP claim transaction if the RAC

adjustment claim meets either of the following conditions:

1) The claim resulted in Medicare changing its payment decision from paid to denied (i.e., Medicare

paid $0.00 as a result of the adjustment performed); or

2) The claim resulted in a Medicare adjusted payment that falls below the amount of the inpatient

hospital deductible.

Prior to sending RAC-initiated adjustment claims with all other type of bill designations to CWF for

normal processing, the A/ B MAC (Part A) and A/B MAC (Part HHH) shared system shall input an “R”

indicator in the newly defined header field of the HUOP, HUHH, and HUHC claim.

Prior to sending their processed RAC adjustment transactions to CWF for normal verification and

validation, the A/B MAC (Part B) and DME MAC shared systems shall input the “R” indicator in the newly

defined header field of the HUBC and HUDC claim transactions.

Unique COBA ID Assignment to Trading Partners That Accept RAC-Initiated Adjustment Claims

Only and Attendant A/B MAC and DME MAC Responsibilities

The BCRC will assign a unique COBA ID range (88000-88999) to COBA trading partners that elect to

“include” RAC-initiated adjustment claims for crossover purposes and will not, at CMS’s direction, charge

the trading partner the standard crossover fee for that category of adjustment claims. Therefore, when A/B

MACs and DME MACs receive a BOI reply trailer (29) on a claim that contains only a COBA ID in the

range 88000 through 88999 (which designates RAC adjustment), the A/B MAC and DME MAC shall not

expect payment for the claim.

Before the A/B MAC and DME MAC shared systems send “tagged” RAC-initiated adjustment claims to the

BCRC via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the

fields that correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file

only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:

1) Populate “ADD” in the field that corresponds to NTE01; and

2) Populate “RA,” utilizing bytes 01 through 02, in the field that corresponds to NTE02.

III. CWF Crossover Processes In Association with the Coordination of Benefits Contractor

A. CWF Processing of the COBA Insurance File (COIF) and Returning of BOI Reply Trailers

Effective July 6, 2004, the BCRC began to send initial copies of the COBA Insurance File (COIF) to the

nine CWF host sites. The COIF contains specific information that will identify the COBA trading partner,

including name, COBA ID, address, and tax identification number (TIN). It also contains each trading

partner’s claims selection criteria along with an indicator (Y=Yes or N=No) of whether the trading partner

wishes its name to be printed on the Medicare Summary Notice (MSN). Effective with the October 2004

systems release, the COIF also contains a 1-digit Test/Production Indicator that will identify whether a

COBA trading partner is in test (T) or production (P) mode. The CWF shall return that information as part

of the BOI reply trailer (29) to A/B MACs and DME MACs.

Upon receipt of a claim, CWF shall take the following actions:

• Search for a COBA eligibility record on the BOI auxiliary record for each beneficiary and obtain the

associated COBA ID(s) [NOTE: There may be multiple COBA IDs associated with each

beneficiary.];

• Refer to the COIF associated with each COBA ID NOTE: The CWF shall pull the COBA ID from

the BOI auxiliary record to obtain the COBA trading partner’s name and claims selection criteria;

• Apply the COBA trading partner’s selection criteria; and

• Transmit a BOI reply trailer to the A/B MAC and DME MAC only if the claim is to be sent, via 837

COB flat file or NCPDP file, to the BCRC to be crossed over.

B. BOI Reply Trailer and Claim-based Reply Trailer Processes

1. BOI Reply Trailer Process

For eligibility file-based crossover, all A/B MACs and DME MACs shall send processed claims

information to the BCRC for crossover to a COBA trading partner in response to the receipt of a

CWF BOI reply trailer (29). A/B MACs and DME MACs will only receive a BOI reply trailer (29)

under the consolidated crossover process for claims that CWF has selected for crossover after

reading each COBA trading partner’s claims selection criteria as reported on the weekly COIF

submission.

When a BOI reply trailer (29) is received, the COBA assigned ID will identify the type of crossover

(see the Data Elements Required for the BOI Aux File Record Table in Chapter 27, §24). Although

each COBA ID will consist of a five-digit prefix that will be all zeroes, A/B MACs and DME MACs

are only responsible for picking up the last five digits within these ranges, which will be right

justified in the COBA number field. In addition to the trading partner’s COBA ID, the BOI reply

trailer shall also include the COBA trading partner name (s), an “A” crossover indicator that

specifies that the claim has been selected to be crossed over, and a one-digit indicator [“Y”=Yes;

“N”=No] that specifies whether the COBA trading partner’s name should be printed on the

beneficiary MSN. As discussed above, effective with the October 2004 systems release, CWF shall

also include a 1-digit Test/Production Indicator on the BOI reply trailer (29) that is returned to the

A/B MACs and DME MACs.

MSN Crossover Messages

Effective with the October 2004 systems release, the A/ B MACs and DME MACs began to receive

BOI reply trailers (29) that contain an MSN indicator “Y” (Print trading partner name on MSN) or

“N” (Do not print trading partner name on MSN).

When a COBA trading partner is in full production (Test/Production Indicator=P), the A/ B MAC

and DME MAC shall read the MSN indicator returned on the BOI reply trailer (29). If the A/B

MAC or DME MAC receives an MSN indicator “N,” it shall print its generic crossover message(s)

on the MSN rather than including the trading partner’s name. Examples of existing generic MSN

messages include the following:

(For all COBA ID ranges other than Medigap)

MSN #35.1 - “This information is being sent to private insurer(s). Send any questions regarding

your benefits to them.”

(For the Medigap COBA ID range)

MSN#35.2 - “We have sent your claim to your Medigap insurer. Send any questions regarding your

Medigap benefits to them.”

Beginning with the October 2004 systems release, A/B MACs and DME MACs shall follow these

procedures when determining whether to update its claims history to show that a beneficiary’s claim

was selected by CWF to be crossed over.

• If the A/B MAC or DME MAC receives a BOI reply trailer (29) that contains a

Test/Production Indicator “T,” it shall not update its claims history to show that a

beneficiary’s claim was selected by CWF to be crossed over.

• If the A/B MAC or DME MAC receives a BOI reply trailer (29) that contains a

Test/Production Indicator “P,” it shall update its claims history to show that a beneficiary’s

claim was selected by CWF to be crossed over.

Effective January 5, 2009, when CWF returns a BOI reply trailer (29) to an A/B MAC and DME

MAC that contains only a COBA ID in the range 89000 through 89999, the A/B MAC and DME

MAC shared system shall suppress all crossover information, including name of insurer and generic

message#35.1, from all beneficiary MSNs.

A/B MACs and DME MACs shall not update their claims histories to reflect transference of

“tagged” claims with COBA ID range 89000 through 89999 to the BCRC.

ASC X12 835 (Electronic Remittance Advice)/Provider Remittance Advice Crossover Messages

Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a

“T” Test/Production Indicator to the A/B MACs and DME MACs, they shall not print information

received from the BOI reply trailer (29) in the required crossover fields on the ASC X12 835

Electronic Remittance Advice or other provider remittance advices that are in production.

Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a

“P” Test/Production Indicator to the A/B MACs and DME MACs, they shall use the returned BOI

trailer information to take the following actions on the provider’s 835 Electronic Remittance Advice:

a. Input code 19 in CLP-02 (Claim Status Code) in Loop 2100 (Claim Payment Information) of

the 835 ERA (v. 4010-A1). [NOTE: Record “20” in CLP-02 (Claim Status Code) in Loop

2100 (Claim Payment Information) when Medicare is the secondary payer.]

b. Update the 2100 Loop (Crossover Contractor Name) on the 835 ERA as follows:

• NM101 [Entity Identifier Code]—Use “TT,” as specified in the 835 Implementation Guide.

• NM102 [Entity Type Qualifier]—Use “2,” as specified in the 835 Implementation Guide.

• NM103 [Name, Last or Organization Name]—Use the COBA trading partner’s name that

accompanies the first sorted COBA ID returned to you on the BOI reply trailer.

• NM108 [Identification Code Qualifier]—Use “PI” (Payer Identification)

• NM109 [Identification Code]—Use the first COBA ID returned to you on the BOI reply trailer.

(See line 24 of the BOI aux. file record

Effective with January 5, 2009, if CWF returns only COBA ID range 89000 through 89999 on a BOI

reply trailer (29) to an A/B MAC and DME MAC, the associated shared system shall suppress all

crossover information (the entire 2100 loop) on the 835 ERA.

CWF Sort Routine for Multiple COBA IDs

Effective with October 3, 2011, when a beneficiary’s claim is associated with more than one COBA

ID (i.e., the beneficiary has more than one health insurer/benefit plan that pays after Medicare), CWF

shall sort the COBA IDs and trading partner names in the following order on the returned BOI reply

trailer (29): 1) Eligibility-based Medigap (30000-54999); 2) Medigap claim-based (55000-59999); 3)

Supplemental (00001-29999); 4) Other Insurer (80000-80213); 5) Other Insurance (80215-88999); 6)

TRICARE (60000-69999); 7) CHAMPVA (80124); 8) Medicaid (70000-79999); and 9) Other-Health Care Pre-payment Plan [HCPP] (89000-89999). When two or more COBA IDs fall in the

same range (see element 24 of the “Data Elements Required for the BOI Aux File Record” Table in

chapter 27, §80.4 for more details), CWF shall sort numerically within the same range.

IV. A/B MAC and DME MAC Actions Relating to the Transition to the ASC X12 837 Version 5010

and NCPDP Version D.O

A. CWF COIF and BOI Reply Trailer (29) Processes

Effective January 5, 2009, the BCRC , at CMS’s direction, created a new 1-byte “5010 Test/Production

Indicator” and a new 1-byte “NCPDP D.0 Test/Production Indicator” on the COBA Insurance File [COIF]

(valid values= “N”—not applicable or not ready as yet; “T”—test; “P”—production). In addition, the CWF

maintainer shall add a new “5010 Test/Production Indicator” and an “NCPDP D.0 Test/Production

Indicator” to the BOI reply trailer (29) format. (See Pub.100-04 chapter 27, §80.7 for additional details

regarding CWF requirements relating to the new crossover claim formats.)

B. Transmission of the COB Flat File or NCPDP File to the BCRC

Regardless of whether a COBA trading partner is in test mode (Test/Production Indicator returned via the

BOI reply trailer 29=T) or production mode (Test/Production Indicator returned via the BOI reply trailer

29=P), A/B MACs and DME MACs shall transmit all non-NCPDP claims received with a COBA ID via a

BOI reply trailer to the BCRC in an ASC X12 837 flat file, as described in Transmittal AB-03-060. In a

separate transmission, DME MACs shall send the claims received in the NCPDP file format to the BCRC.

A/B MACs and DME MACs shall enter the 5-digit COBA ID picked up from the BOI reply trailer (29) in

the 1000B loop of the NM1 segment in the NM109 field. In a situation where multiple COBA IDs are

received for a claim, A/B MACs and DME MACs shall send a separate ASC X12 837 or NCPDP

transaction to the BCRC for each COBA ID. A/B MACs and DME MACs shall perform the transmission at

the end of their regular batch cycle, when claims are removed from their payment floor, to ensure crossover

claims are not processed by the COBA trading partner prior to Medicare’s final payment. Transmission to

the BCRC shall occur via Connect: Direct or other CMS dictated connectivity.

Effective with October 4, 2005, when the A/B MAC and DME MAC shared systems transfer processed

claims to the BCRC as part of the COBA process, they shall include an additional 1-digit alpha character

(“T”=test or “P”=production) as part of the BHT03 identifier (Beginning of the Hierarchical Transaction

Reference Identification) that is included within the ASC X12 837 flat file or NCPDP submissions. The

shared systems shall determine that a COBA trading partner is in test or production mode by referring to the

BOI reply trailer (29) originally received from CWF for the processed claim. (See §70.6.1 of this chapter for

further details about the BHT03 identifier.)

Effective October 2, 2006, the Virtual Data Center (VDC), formerly the Enterprise Data Centers (EDCs),

shall transmit a combined COBA “test” and “production” ASC X12 837 flat file and a combined “test” and

“production” NCPDP file, as applicable, to the BCRC.

NOTE: This requirement changes the direction previously provided in October 2005 through the issuance

of Transmittal 586.

Flat File Conventions for Transmission to the BCRC For Production COBA Crossover Claims Prior

to July 2012

With respect to ASC X12 837 COB flat file submissions to the BCRC, A/B MACs (Part B) and DME

MACs shall observe these process rules:

The following segments shall not be passed to the BCRC:

1. ISA (Interchange Control Header Segment);

2. IEA (Interchange Control Trailer Segment);

3. GS (Functional Group Header Segment); and

4. GE (Functional Group Trailer Segment).

The 1000B loop of the NM1 segment denotes the crossover partner. If multiple COBA IDs are received via

the BOI reply trailer, the shared system shall ensure that a separate ASC X12 837 transaction should be

submitted for each COBA ID received. As the crossover partner information will be unknown to the

standard systems, the following fields should be formatted as indicated for the NM1 segment:

NM103—Use spaces; and

NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).

The 2010BA loop denotes the subscriber information. If available, the subscriber name, address, and policy

number should be used to complete the NM1, N3, and N4 segments. If unknown, the segments should be

formatted as follows, with BCRC completing any missing information:

NM1 segment—For NM103, NM104, NM105, and NM107, use spaces;

NM1 segment—For NM109, include beneficiary’s Medicare beneficiary identifier;

N3 segment—Use all spaces; and

N4 segment—Use all spaces.

The 2010BB loop denotes the payer name. Per the HIPAA Implementation Guide (IG), this loop should

define the secondary payer when sending the claim to the second destination payer. Consequently, given

that the payer related to the COBA ID will be unknown by the standard systems, the NM1, N3, and N4

segments should be formatted as follows, with BCRC completing any missing information:

NM1 segment—For NM103, use spaces;

NM1 segment—For NM109, include the COBA ID (5-digit COBA ID picked up from the BOI reply

trailer 29);

N3 segment—Use all spaces; and

N4 segment—Use all spaces.

The 2330B loop denotes other payers for the claim. If multiple COBA IDs are returned via the BOI reply

trailer, payer information for the additional COBA IDs will be unknown. As with the 2010BB loop, the

NM1 segment should be formatted as follows, with BCRC completing any missing information:

NM103—Use spaces; and

NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).

The 2330B loop shall be repeated to allow for the inclusion of the name (NM103) and associated Trading

Partner ID (NM109) for each existing trading partner.

The 2320 loop denotes other subscriber information. Within the SBR segment, the SBR03 and SBR04

segments are used to define the group/policy number and insured group name, respectively. If the

information is available for these fields, those values should be propagated accordingly for both current

trading partners and COBA trading partners. The BCRC will inspect these values for COBA related

eligibility based claims and overlay as appropriate. Spaces should only be used for COBA-related

situations.

SBR01—Treat as normally do.

With respect to ASC X12 837 COB flat file submissions to the BCRC, A/B MACs (Part A) and A/B MACs

(Part HHH) shall observe these process rules:

As the ISA, IEA, and GS segments are included in the “100” record with other required segments,

the “100” record must be passed to the BCRC. However, as the values for these segments will be

recalculated, spaces may be placed in all of the fields related to the ISA, IEA, and GS segments.

The 1000B loop of the NM1 segment denotes the crossover trading partner. If multiple COBA IDs are

received via the BOI reply trailer, the A/B MAC or DME MAC system shall ensure that a separate 837

transaction should be submitted for each COBA ID received. As the crossover trading partner information

will be unknown to the standard systems, the following fields should be formatted as follows for the NM1

segment on the”100” record:

NM103—Use spaces; and

NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).

The 2010BA loop denotes the subscriber information. If available, the subscriber name, address, and policy

number should be used to complete the NM1, N3, and N4 segments. If unknown, the segments should be

formatted as follows for the “300” record, with BCRC completing any missing information:

NM1 segment – For NM103, NM104, NM105, and NM107, use spaces;

NM1 segment—For NM109, include beneficiary’s Medicare beneficiary identifier;

N3 segment—Use all spaces; and

N4 segment—Use all spaces.

The 2010BC loop denotes the payer name. Per the HIPAA IG, this loop should define the secondary payer

when sending the claim to the second destination payer. Consequently, since the payer related to the COBA

ID will be unknown to the standard systems, the NM1, N3, and N4 segments should be formatted as follows

for the “300” record, with BCRC completing any missing information:

NM1 segment—For NM103, use spaces;

NM1 segment—For NM109, include COBA ID (5-digit COBA ID picked up from the BOI reply

trailer 29);

N3 segment—Use all spaces; and

N4 segment—Use all spaces.

The 2330B loop of the “575” record denotes other payers for the claim. If multiple COBA IDs are returned

via the BOI reply trailer, payer information for the additional COBA IDs will be unknown. As with the

2010BC loop, the NM1 segment should be formatted as follows, with BCRC completing any missing

information:

NM103—Use spaces; and

NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).

The 2330B loop shall be repeated to allow for the inclusion of the name (NM103) and associated Trading

Partner ID (NM109) for each existing trading partner.

The 2320 loop denotes other subscriber information. Within the SBR segment, the SBR03 and SBR04

segments are used to define the group/policy number and insured group name, respectively. If the

information is available for these fields, those values should be propagated accordingly. The BCRC will

inspect these values for COBA related eligibility based claims and overlay as appropriate. Spaces should

only be used for COBA-related situations.

SBR01—Treat as normally do.

C. BCRC Processing of COB Flat Files or NCPDP Files

Effective April 5, 2021, the COB&R system supporting the BCRC will transmit modified dataset names to

the VDCs for the COBA Claims Response File (the File whereby the BCRC, through the COB&R system,

conveys an acceptance of the flat file with the value “A” or rejection of the file with the value“R”). The

VDCs shall be prepared to accept the following modified dataset names effective April 5, 2021:

• xxxx.FISP.HBADR.GHI.COB5RESP(+1) [For 837 institutional claims]

• xxxx.MCSP.HBXDR.ADyyCOBC(+1) [For 837 non-DMEPOS professional claims]

• xxxx.VMSP.COBC.A5010.ERROR.RESPONSE(+1) [For 837 DMEPOS professional claims]

• Value is TBD [For NCPDP Part B Drug Claims] (Note: Since the implementation of NCPDP D.0

COB claims as part of COBA, the VDCs have not been set up to receive NCPDP Claim Response

Files.)

Note the following definitions that apply to the above Claim Response File dataset names:

• VDCx= directs the file to the appropriate VDC; VDC1 = CD1.EDC1; VDC3 = CD3.EDC1

• xxxx = High-level qualifier (HLQ) identifier currently used by the MAC

• yy = identifier currently used by and defined for Part B files for Plan Code

When an A/B MAC and DME MAC receives the reject indicator “R” via the Claims Response File, it is to

retransmit the entire file to the BCRC. If the A/B MAC or DME MAC receives an acceptance indicator

“A,” this confirms that its entire COB flat file or NCPDP file transmission was accepted. Once COB flat

files or NCPDP files are accepted and translated into the appropriate outbound format(s), BCRC will cross

the claims to the COBA trading partner. The format of the Claims Response File that will be returned to

each A/B MAC and DME MAC by the BCRC, following its COB ASC X12 837 flat file or NCPDP file

transmission, appears in the table below. (See §70.6.1 for specifications regarding the receipt and processing

of the BCRC Detailed Error Reports.)

Claims Response File Layout (80 bytes)

Field Name Size Displacement Description

1 A/B MAC or DME

MAC Number

5 1-5 A/B MAC or DME MAC

Identification Number

2 Transaction Set

Control Number/

Batch Number

9 6-14 Found within the ST02 data element

from the ST segment of the ASC X12

837 flat file or in field 806-5C from the

batch header of the NCPDP file.

3 Number of claims 9 15-23 Number of Claims contained in the

ASC X12 837 flat file or NCPDP file.

This is a numeric field that will be

right justified and zero-filled.

4 Receipt Date 8 24-31 Receipt Date of ASC X12 837 flat file

or NCPDP file in CCYYMMDD

format

5 Accept/Reject

indicator

1 32 Indicator of either the acceptance or

rejection of the ASC X12 837 flat file

or NCPDP file. Values will either be

an “A” for accepted or “R” for

rejected.

6 Filler 48 33-80 Spaces

Claims response files will be returned to A/B MACs and DME MACs after receipt and initial processing of

a claim file. Thus, for example, if an A/B MAC or DME MAC sends a COB flat file daily via the VDC, the

BCRC will return a claim response file to that entity on a daily basis.

Effective April 5, 2021, VDC-transmitted ASC X12 COB 837 flat files and NCPDP files submitted by the

VDC on behalf of each A/B MAC and DME MAC, as applicable, to the CMS Baltimore Data Center (BDC)

to, in turn, be transmitted to the Coordination of Benefits & Recovery (COB&R) system supporting BCRC

will be assigned the following file dataset names, regardless of whether a COBA trading partner is in test or

production mode:

• P/T#EFT.ON.COBA.Cxxxxx.PARTA.Dyymmdd.Thhmmsst [For Institutional Claims}

• P/T#EFT.ON.COBA.Cxxxxx.PARTB.Dyymmdd.Thhmmsst [For Professional Claims]

• P/T#EFT.ON.COBA.Cxxxxx.NCPDP.Dyymmdd.Thhmmsst [For NCPDP Part B Drug Claims]

Note the following definitions that apply to the dataset names above:

• P/T= “P”—Production; “T”= Test

• Cxxxxx= C + the 5-digit MAC ID; e.g., 12302

• Dyymmdd.Thhmmsst = Current date and Time concatenated to literals D and T. (NOTE: This is

optional for the VDCs to include, and if not present, CMS EFT will concatenate it.)

A/B MACs and DME MACs shall perform the ASC X12 837 flat file and NCPDP file transmission at the

end of the regular batch cycle, when claims come off the payment floor, to ensure crossover claims are not

processed by the trading partner prior to Medicare’s final payment.

Files transmitted by the VDC to the BCRC shall be stored for 51 business days from the date of

transmission.

The file names for the Claims Response File returned to the A/B MAC and DME MAC via the VDC will be

created as part of the NDM set-up process.

Outbound COB files transmitted by BCRC to the COBA trading partners will be maintained for 50 business

days following the date of transmission.

E. The COBA Medigap Claim-Based Process Involving CWF

Refer to §70.6.4 of this chapter for more information regarding this process.

F. COBA Customer Service Issues

1. Customer Service

a. A/ B MACs and DME MACs shall use the BCRC and CMS COBA Problem Inquiry Request

Form to identify and send COBA related problems and issues to the COB contractor for research.

In order to track trading partner requests for research of 837 ASC X12 issues, CMS requires A/B

MACs and DME MACs to submit a COBA Problem Inquiry Request Form to the BCRC or

CMS. This process is being implemented to reduce the number of duplicate issues being

researched and to ensure your requests are processed timely. The standard form enables CMS

and BCRC to track issues through completion and manage the process of addressing post-COBA

production issues. Upon receipt the submitter shall receive a response from the BCRC with the

assigned contact information.

CMS is also requiring A/B MACs and DME MACs to use the COBA Problem Inquiry Request

Form when requesting a BCRC representative to research a COBA issue. The combined BCRC-

CMS COBA Problem Inquiry Request Form appears below.

A/B MAC and DME MAC: COBA PROBLEM INQUIRY REQUEST FORM

Completed by Submitter – control number if applicable Write in this column only

MAC ID# (Enter the A/B MAC or DME MAC

ID # assigned by CMS)

MAC Reference ID (If applicable - BHT03)

Reported By (Enter submitter’s last name, first

name)

Date Submitted (Enter current date –

MM/DD/YR)

Contact # (Enter submitter’s phone #)

E-mail Address (Enter submitter’s e-mail

address)

COBA ID #

Description of Problem (Check applicable category)

HIPAA Error Code

ICN Date (Date file was transmitted to the

BCRC)

HIPAA Error Code(s)

Part A/Part B/NCPDP Claim

Technical Issue (Claims file transmission failures)

File Name

Transmission Date

Summary of Issue- Provide detail of problem and note if back-up information will be faxed, e.g., Sample

Claims to be Faxed on MM/DD/YR. Indicate whether you would like your issue on the next HIPAA

issues log – do not include any PHI information on this form if sent via email. All PHI information

must be submitted via fax to the BCRC to the attention of your BCRC representative at 646-458-6761.

Do not include PHI information on the fax cover sheet. Claim examples of issues to be addressed

must include the beneficiary Medicare beneficiary identifier and the claim ICN/DCN.

BCRC USE ONLY. Date: Ticket #:

V. Identification of Mass Adjustments for COBA Crossover Purposes

All A/B MACs and DME MACs and their shared systems shall develop a method for differentiating “mass

adjustments tied to the Medicare Physician Fee Schedule (MPFS) updates” and “all other mass adjustments”

from all other kinds of adjustments and non-adjustment claims.

NOTE: For appropriate classification, all adjustments that do not represent “mass adjustments-MPFS” or

“mass adjustments-other” shall be regarded as “other adjustments.”) DME MACs and their

shared system shall only be required to identify mass adjustments-other, which represents a

current functionality available within VMS. This is because DME MACs do not use pricing

from the MPFS when processing their claims.

Working Definition of “Mass Adjustment”

For COBA crossover purposes, a “mass adjustment” refers to an action that an A/B MAC or DME MAC

undertakes using special software (e.g., Super-Op Events or Express Adjustments) to pull together claims

with the anticipated purpose of making monetary changes to a high number of those claims. If, however,

A/B MACs and DME MACs do not have special software to perform high volume adjustments (i.e.,

typically adjustments to 100 or more claims), but instead must perform their high volume adjustments

manually, this action also fulfills the definition of a “mass adjustment.”

Inputting a One-Byte Header Value on Claim Transactions to Designate Mass Adjustment and

Associated Processes

Before A/B MACs and DME MACs cable their claims to CWF for verification and validation, they shall

populate a 1-byte “mass adjustment” indicator in the header of their HUBC, HUDC, HUIP, HUOP, HUHH,

or HUHC entry code “5” or action code “3” claim transactions. The CWF maintainer shall create a new 1-byte field within the header of its HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC claims transactions for

this purpose.

A/ B MACs and DME MACs shall determine whether the “M” or “O” indicator applies in relation to a

given claim at the point that they initiate a mass adjustment action on that claim using a manual process or

an automated adjustment process; e.g., Super Op Events or Express Adjustments. Upon making this

determination, the A/B MACs and DME MACs and their shared systems shall populate one (1) of the

following mass adjustment claim indicators, specific to the particular claim situation, within the header of

the A/B MACs or DME MACs’ processed claims that they will cable to CWF for verification and

validation:

“M”—if mass adjustment claim tied to an MPFS update; or

“O”—if mass adjustment claim-other.

If A/B MACs and DME MACs send values other than “M” or “O” within the newly designated field within

the header of their HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC entry code “5” or action code “3”

claims, CWF shall apply an edit to reject the claims back to the MAC. Upon receipt of the CWF rejection

edit, the shared systems shall correct the invalid value and retransmit the claims to CWF for verification and

validation.

Important: Effective January 5, 2026, CWF shall begin accepting the value “N” (defined as Affordable Care

Act (ACA) mass adjustment) in the header of HUIP, HUOP, HUHH, or HUHC claims for situations where

CMS specifically directs that ACA mass adjustments be initiated and processed. Additionally, CWF shall

modify its Part A consistency edit 0045 to accept the new Mass Adjustment Indicator value of “N.” This

value may be generated by the Part A shared system or by a MAC (A, HHH). Only in this scenario will the

Part A shared system map the value “P” (Affordable Care Act mass adjustment) to the 23rd position of the

BHT03 file identifier on outbound 837 crossover claims.

VI. Special ASC X12 835 Remittance Advice and MSN Requirements for Health Care Pre-Payment

Plans (HCPPs) and Health Maintenance Organization (HMO) Cost Plans that Receive Crossover

Claims

Effective January 5, 2009, at CMS’s direction, the BCRC assigned all COBA HCPP and HMO Cost Plan

participants a unique 5-byte COBA ID that falls within the range 89000 through 89999. The CWF system

shall accept the reporting of this COBA ID range.

Upon receipt of a BOI reply trailer (29) that contains only a COBA ID in the range 89000 through 89999, the

A/B MAC and DME MAC shared systems shall suppress all crossover information (including name of the

insurer; generic message; and specific code (for ASC X12 835, code MA-18; for MSN, code 35.1) indicating

that the claim will be crossed over) from the associated ASC X12 835 remittance advice and beneficiary

MSN. (See §70.6.1 of this chapter for A/B MAC or DME MAC requirements relating to the BCRC Detailed

Error Report processes and receipt of claims that contain COBA ID range 89000 through 89999.)

VII. Special Suppression Requirements for Part A Credit Claim Portion of Debit-Credit Claim Pairing

Effective with the April 2009 release, the A/B MAC (Part A) and A/B MAC (Part HHH) shared system shall

suppress sending the credit claim portion of the debit-credit pairing (that transaction which cancels the

original claim) associated with each affiliated A/B MAC’s (A, HHH) adjustment claims to the BCRC. Upon

suppressing the credit claim, the A/B MAC (Part A) and A/B MAC (Part HHH) system shall mark the

claims history of its affiliate MAC to reflect this action.