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

Notification Process

(Rev. 13314; Issued: 07-24-25; Effective: 01-01-26; Implementation: 01-05-26)

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.

Effective with the July 2005 release, CMS implemented an automated process to notify physicians/

practitioners, suppliers, and providers that specific claims that were previously tagged by the Common

Working File (CWF) for crossover will not be crossed over due to claim data errors. Claims transmitted via

ASC X12 837 flat file by the A/B MAC and DME MAC shared systems to the Benefits Coordination &

Recovery Center (BCRC) may be rejected at the flat file level, at a HIPAA ASC X12 pre-edit validation

level, or by trading partners as part of a financial dispute arising from an invoice received.

Effective with the April 2005 release, the A/B MAC and DME MAC shared systems began to populate the

BHT 03 (Beginning of Hierarchical Reference Identification) portion of their ASC X12 837 COB flat file

submissions to the BCRC with a unique 22-digit identifier. This unique identifier will enable the BCRC to

successfully tie a claim that is rejected by the BCRC at the flat file or HIPAA ASC X12 pre-edit validation

levels as well as claims disputed by trading partners back to the original ASC X12 837 flat file submissions.

Effective October 4, 2005, A/ B MACs and DME MACs and their shared systems began to receive

notification via the BCRC Detailed Error Reports, whose file layout structures appear below, that a COBA

trading partner is in test or production mode via the BHT 03 identifier that is returned from the BCRC.

Effective April 3, 2011, all A/B MACs and DME MACs shall include an extra 1-byte “Original versus

Adjustment Claim Indicator” value within the BHT03 identifier on all ASC X12 837 institutional and

professional claims they transmit to the BCRC for crossover purposes. The BCRC shall, in turn, return this

value to the appropriate A/B MAC and DME MAC via the BCRC Detailed Error Report process. In

addition, the DME MAC shared system shall send an additional 1-byte value (defined as “reserved for future

use”) as spaces in field 504-F4 (Message) of the NCPDP flat file sent to the BCRC. The BCRC shall, in

turn, also return this value to the appropriate DME MAC via the BCRC Detailed Error Report process.

Effective April 1, 2013, CMS added a new 1-byte Original versus Adjustment indicator to the suite of

possible 1-byte options for position 23 of the BHT03 identifier, as reflected below.

Effective with April 7, 2014, CMS has added 2 new 1-byte Original versus Adjustment indicators to the

suite of possible options for position 23 of the BHT03 identifier, as reflected below.

A. Inclusion of the Unique 23-Digit Identifier on the ASC X12 837 Flat File and NCPDP File

1. Populating the BHT 03 Portion of the ASC X12 837 Flat File

The A/B MAC and DME MAC shared systems shall populate the BHT 03 (Beginning of Hierarchical

Transaction Reference Identification; field length=30 bytes) portion of their ASC X12 837 flat files that are

sent to the BCRC for crossover with a 23-digit Contractor Reference Identifier (CRI). The identifier shall be

formatted as follows:

a. A/B MAC or DME MAC number (9-bytes; until the 9-digit MAC number is used, report the 5-digit

MAC number, left-justified, with spaces for the remaining 4 positions);

b. Julian date as YYDDD (5 bytes);

c. Sequence number (5 bytes; this number begins with “00001,” so the sequence number should

increment for each ST-SE envelope, which is specific to a trading partner, on a given Julian date);

d. Claim version indicator (2 bytes, numeric, to denote claim version)

**Acceptable values = 50 (for ASC X12 claims), and 20 (for NCPDP D.0 claims);

e. COBA Test/Production Indicator (1-byte alpha indicator; acceptable values = “T” [test] and “P”

[production]) or “R” if the claims were recovered for a “production” COBA trading partner (see

§70.6.3 of this chapter for more details;

f. Original versus Adjustment Claim Indicator (1-byte alpha indicator); acceptable values are defined

as the following:

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; and

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

The following indicator is only applicable to FISS-generated claims:

V - Void/cancel only claim

The 23-digit CRI shall be left-justified in the BHT 03 segment of the 837 flat file, with spaces used for the

remaining 8 positions. (NOTE: The CRI is unique inasmuch as no two files should ever contain the same

combination of numbers.)

Clarification Regarding Use of Original Versus Adjustment Claim Indicator Values

BHT03 Position 23 Value “P”

• Effective January 5, 2026, MACs shall discontinue their actions that result in the value "P" being

populated in the 23rd position of the BHT03 file identifier of outbound 837 COBA crossover claims.

(Note: This action is requested because the use of "P" is only appropriate when CMS directs its

MACs to reprocess large volumes of claims due to specific changes to ACA provisions. The value

"P" shall remain in effect, but the value shall only be used as CMS directs.)

FISS shall ensure that its associated Part A MACs (AA, HHH) are able to comply with this

requirement by virtue of the creation of a new Mass Adjustment Indicator field value of “N.” FISS

and its associated MACs shall only send this value to the Common Working File (CWF) when

Affordable Care Act (ACA) mass adjustments are being created and processed in accordance with

CMS direction (see Pub.100-04, chapter 27, section 80.6 for more information).

For MACs (Part B) to comply with this requirement, they shall take the following action:

o Review the HxxTCACT spi-tab to temporarily remove any records with a "P" indicator unless

they are needed for CMS specifically directed mass adjustment transactions tied to a

future ACA update.

BHT03 Position 23 Value M

• MACs (Part B) shall only trigger the value "M" for the 23rd position of the BHT03 file identifier in

the following circumstance:

o When CMS has specifically directed them and/or their shared system(s) to mass adjust large

volumes of claims (i.e., typically 1 million or greater) due to a needed change that has been

implemented to the Medicare Physician Fee Schedule (MPFS), such that the approved

amounts have been adjusted downward or upward due to a legislative or regulatory change.

(Note: This scenario is unique to MPFS changes only and would apply to an entire timeframe

within a given year or a previous year, e.g., from January 1 to June 30 or, for the previous

year, from January 1 through December 31.)

• For MACs (Part B) to comply with this request, they shall:

o Review the HxxTCACT spi-tab to temporarily remove any records with an "M" indicator

unless they are needed for CMS specifically directed mass adjustment transactions tied to

MPFS updates.

When CMS has directed MACs (Part B) to perform mass adjustments following an update to the MPFS, the

MACs (Part B) shall continue to map the value "M" to the Mass Adjustment Indicator claim header field.

(Note: This action will ensure that the Common Working File has the information it needs to exclude

mass adjustments/MPFS as applicable; see Pub.100-04, chapter 7, section 80.6 for more information

regarding this subject.)

Important: MACs (Part B) shall not trigger the value "M" when they are merely correcting claims that were

processed incorrectly due to a non- MPFS systematic issue (e.g., reprocessing a whole series of

demonstration project claims because the claims originally were not processed with the appropriate

demonstration project reduction amounts reflected). Instead, they shall trigger the value “S” for the 23rd

position of the BHT03 file identifier for this scenario.

Normal Mass Adjustment Claims Scenarios and Recovery Audit Contractor Claims Adjustment

Activities

Unless CMS has directed the MACs to include the value "C" in the 23rd position of the BHT03, MACs shall

otherwise take action to trigger the value "S" (mass adjustment--other) in the 23rd position of the BHT03

file identifier when adjudicating mass adjustment claims that do not represent bona-fide MPFS adjustments.

This guidance applies unless the claims represent Recovery Audit Contractor (RAC) adjustment claims

(which often are effectuated as mass adjustments), in which case the value “R” shall be triggered.

Routine Adjustments

As of January 5, 2026, all MACs shall continue to trigger value "A" for routine adjustment claims (i.e., non-mass adjustment claims) in position 23 of the BHT03 file identifier. This would not apply when the MAC is

handling RAC-related adjustments. For that scenario, the MAC would trigger the value “R” for the 23rd

position of the BHT03 file identifier.

2. NCPDP 23-Digit Unique Identifier

Effective April 3, 2011, the DME MAC shared system shall also adopt a unique 23-digit format, referenced

directly above under “Populating the BHT 03 Portion of the ASC X12 837 Flat File.” However, prior to

April 7, 2014, the system shall populate the unique 23-digit identifier (defined as “future use”) with spaces

in field 504-F4 (Message) within the NCPDP file (field length=35 bytes). The DME MAC shared system

shall populate the unique identifier, left justified, in the field. Spaces shall be used for the remaining bytes

in the field.

Effective April 7, 2014, the DME MAC shared system shall ensure that its DME MACs have the ability to

1) execute actions that will result in the transmission of their HUDC claims to CWF with Mass Adjustment

Indicator set to “O”; and 2) transmit mass adjusted NCPDP D.0 COB claims to the BCRC under a 504-F04

(Message) field identifier of "C" (CMS-directed mass adjustment action) or "P" (mass adjustments tied to

Affordable Care Act or Congressional/legislative mandate) as appropriate to the situation.

In addition, the DME MAC shared system shall ensure that all NCPDP D.0 crossover claims will now be

sent to the BCRC with the 23rd byte 504-F04 (Message) field indicator completed, when appropriate, as

indicated below.

O -- for all "original" NCPDP D.0 claims transmitted;

A-- for "routine adjustment claims" transmitted; and

R-- for recovery audit claims (RAC) adjustment claims transmitted.

B. BCRC Institutional, Professional, and NCPDP Detailed Error Reports

The A/B MAC and DME MAC shared systems shall accept the BCRC Institutional, Professional, and

NCPDP Detailed Error Reports received from the COB&R system supporting the BCRC.

Effective with April 5, 2021, the datasets that the COB&R system supporting BCRC will use to convey the

BCRC Detailed Error Reports to the VDCs representing the MACs are as follows:

xxxx.FISP.HBADR.GHI.COB5ERR(+1) [For Institutional Claims]

xxxx.MCSP.HBXDR.ADyy5ERC(+1) [For Professional non-DMEPOS Claims]

xxxx.VMSP.COBC.A5010.ERROR.FILE(+1) [For Professional DMEPOS Claims]

The formats for each of the Detailed Error Reports appear below.

Beginning with July 2007, all A/B MAC and DME MAC systems shall no longer interpret the percentage

values received for ASC X12 837 institutional and professional claim “222” and “333” errors via the BCRC

Detailed Error Reports as if the values contained a 1-position implied decimal (e.g., “038” =3.8 percent).

DME MACs shall also no longer interpret the percentage values received for NCPDP claims for “333”

errors via the BCRC Detailed Error Report for such claims as if the values should contain a 1-position

implied decimal.

In addition, A/B MACs and their systems shall now base their decision-making calculus for initiation of a

claims repair of “111” (flat file) errors upon the number of errors received rather than upon an established

percent parameter, as otherwise described within this section.

Effective with July 2009, the A/B MAC and DME MAC shared systems shall accept the modified versions

of the BCRC Detailed Error Reports for institutional and professional claims as reflected below. As part of

the July 2009 changes, the BCRC will, at CMS’s direction, expand the length of the “error description”

field. (NOTE: This means that the shared systems shall therefore include the expanded error description

code as part of their special provider notification letters.)

The Institutional Error File Layout, including summary portion, will be used for Part A claim files.

BCRC Detailed Error Report

Institutional Error File Layout - (Detail Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Control Number 9 9-17

3 COBA ID 10 18-27

4 Subscriber ID/Medicare ID 12 28-39

5 Claim DCN/ICN 14 40-53

6 Record Number 9 54-62

7 Record/Loop Identifier 6 63-68

8 Segment 3 69-71

9 Element 2 72-73

10 Error Source Code 3 74-76 ('111', '222', or '333')

11 Error/Trading Partner Dispute Code 6 77-82

12 Filler 100 83-182

13 Field Contents 50 183-232

14 BHT 03 Identifier 30 233-262 (23 bytes used)

15 Claim DCN/ICN 23 263-285

16 Error Description 300 286-585

17 Filler 15 586-600

Institutional Error File Layout - (Summary Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Total Number of Claims for Processing Date 10 9-18

3 Number of '111' Errors 10 19-28

4 Number of '222' Errors 10 29-38

5 Percentage of '222' Errors 3 39-41

Field Description Field Size Record Location

6 Number of '333' Errors 10 42-51

7 Percentage of '333' Errors 3 52-54

8 Filler 19 55-73

9 Summary Record ID Error Source Code 3 74-76 ('999')

10 Filler 524 77-600

The Professional Error File Layout, including summary portion, will be used for Part B and DME

MAC claim files.

BCRC Detailed Error Report

Professional Error File Layout - (Detail Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Control Number 9 9-17

3 COBA ID 10 18-27

4 Subscriber ID/Medicare ID 12 28-39

5 Claim DCN/ICN 14 40-53

6 Record Number 9 54-62

7 Record/Loop Identifier 6 63-68

8 Segment 3 69-71

9 Element 2 72-73

10 Error Source Code 3 74-76 ('111', '222', '333')

11 Error/Trading Partner Dispute Code 6 77-82

12 Filler 100 83-182

13 Field Contents 50 183-232

14 BHT 03 Identifier 30 233-262 (23 bytes used)

15 Claims DCN/ICN 23 263-285

16 Error Description 300 286-858

17 Filler 15 586-600

Professional Error File Layout – (Summary Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Total Number of Claims for Processing Date 10 9-18

3 Number of '111' Errors 10 19-28

4 Number of '222' Errors 10 29-38

5 Percentage of '222' Errors 3 39-41

6 Number of '333' Errors 10 42-51

7 Percentage of '333' Errors 3 52-54

8 Filler 19 55-73

9 Summary Record ID Error Source Code 3 74-76 ('999')

10 Filler 524 77-600

The NCPDP Error File Layout, including summary portion, will be used by DME MACs for

Prescription Drug Claims

BCRC Detailed Error Report

NCPDP Error File Layout - (Detail Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Batch Number 7 9-15

Field Description Field Size Record Location

3 COBA ID 5 16-20

4 Medicare ID 12 21-32

5 CCN 14 33-46

6 Record Number 9 47-55

7 Batch Record Type 2 56-57

8 Segment ID 2 58-59

9 Error Source Code 3 60-62 ('111', or '333')

10 Error/Trading Partner Dispute Code 6 63-68

11 Error Description 100 69-168

12 Field Contents 50 169-218

13 Unique File Identifier 30 219-248 (23 bytes used)

14 CCN 23 249-271

15 Filler 18 272-289

NCPDP Error File Layout - (Summary Record)

Field Description Field Size Record Location

1 Date 8 1-8

2 Total Number of Claims for Processing Date 10 9-18

3 Number of '111' Errors 10 19-28

4 Number of '333' Errors 10 29-38

5 Percentage of '333' Errors 3 39-41

6 Filler 18 42-59

7 Summary Record ID Error Source Code 3 60-62 ('999')

10 Filler 524 63-289

If the BCRC has rejected back to the A/B MAC and DME MAC shared system for 2 or more COBA

Identification Numbers (IDs), the shared system shall receive a separate error record for each COBA ID.

Also, if a file submission from a shared system to the BCRC contains multiple provider, subscriber, or

patient level errors for one COBA ID, the shared system will receive a separate error record for each

provider, subscriber, or patient portion of the file on which errors were found.

C. Further Requirements of the COBA Detailed Error Report Notification Process

1. Error Source Code

A/B MACs and DME MACs, or their shared systems, shall use all information supplied in the BCRC

Detailed Error Report (particularly error source codes provided in Field 10 of Attachment B) to (1) identify

shared system changes necessary to prevent future errors in test mode or production mode (Test/Production

Indicator= T or P) and (2) to notify physicians, suppliers, and providers that claims with the error source

codes “111,” “222,” and “333” will not be crossed over to the COBA trading partner.

2. Time Frames for Notification of All MACs Financial Management Staff and Providers

A/B MACs and DME MACs, or their shared systems, shall provide notification to MAC financial

management staff for purposes of maintaining an effective reconciliation of crossover fee/ complementary

credits received within five (5) business days of receipt of the BCRC Detailed Error Report.

Effective with the October 2005 release, A/B MACs and DME MACs and their shared systems shall receive

BCRC Detailed Error Reports that contain BHT03 identifiers that indicate “T” (test) or “P” (production)

status for purposes of fulfilling the provider notification requirements. (Note: The “T” or the P” portion of

the BHT03 indicator will be identical to the Test/Production indicator originally returned from CWF on the

processed claim.)

a) Special Automated Provider Correspondence

A/B MACs and DME MACs, or their shared systems, shall also take the following actions indicated below

only when they determine via the Beneficiary Other Insurance (BOI) reply trailer (29) that a COBA trading

partner is in crossover production mode with the BCRC (Test/Production Indicator=P). After an A/B MAC

or DME MAC, or its shared system, has received a BCRC Detailed Error Report that contains claims with

error source codes of “111” (flat file error), “222” (HIPAA ASC X12 error), or “333” (trading partner

dispute), it shall take the following two specified actions within five (5) business days:

1. Notify the physician/practitioner, supplier, or provider via automated letter or other electronic or

automated method that the claim did not cross over. The letter or report/notification shall include

specific claim information, not limited to, Internal Control Number (ICN)/Document Control

Number (DCN), Medicare beneficiary identifier, Medical Record Number (for Part A only), Patient

Control Number (only if it is contained in the claim), beneficiary name, date of service, and the date

claim was processed.

2. Effective with July 2007, A/B MACs and DME MACs and their systems shall ensure that, in

addition to the standard letter language (the claim(s) was/were not crossed over due to claim data

errors and was/were rejected by the supplemental insurer), their A/B MACs’ and DME MACs’

special provider letters or reports/notifications, which are generated for ‘222’ and ‘333’ error

rejections in accordance with CR 4277, now include the following additional elements, as derived

from the BCRC Detailed Error Report: 1) HIPAA H-series rejection code or other rejection code,

and 2) the rejection code’s accompanying description.

NOTE: A/B MACs or DME MACs, or their shared systems, are not required to reference the COBA

trading partner’s name on the above described automated letter or report/notification, since the

original remittance advice (RA)/electronic remittance advice (ERA) would have listed that

information, if appropriate.

2. Update its claims history to reflect that the claim(s) did not cross over as a result of the generation of

the automated letter or report.

Effective with October 1, 2007, all A/B MACs and DME MACs shall modify their special provider

notification letters that are generated for “111,” “222,” and “333” error situations to include the

following standard language within the opening paragraph of their letters or reports: “This claim(s)

was/were not crossed over due to claim data errors or was/were rejected by the supplemental

insurer.”

A/B MACs and DME MACs shall reformat their provider notification letters or reports to ensure

that, in addition to the new standard letter language, they continue to include the rejection code and

accompanying description, as derived from the BCRC Detailed Error Report, for “222” or “‘333”

errors in association with each errored claim.

Effective with the July 7, 2009, release, upon receipt of the BCRC Detailed Error Report (DER), the

A/B MAC (A) and A/B MAC (HH) shared system shall configure the existing 114 report, as derived

from the BCRC DER, so that it: 1) continues to display in landscape format; and 2) includes a cover

page that contains the provider’s correspondence mailing address.

b) Special Exemption from Generating Provider Notification Letters/Reports

Effective July 7, 2008, upon their receipt of BCRC Detailed Error Reports that contain “222” error

codes 000100 (“Claim is contained within a BHT envelope previously crossed; claim rejected”) and

00010 (“Duplicate claim; duplicate ST-SE detected”), all shared systems shall automatically

suppress generation of the special provider notification letters or reports/notifications that they would

normally generate for their associated A/B MACs and DME MACs in accordance with the

requirements of this section as well as §70.6.3 of this chapter. In addition, upon receipt of BCRC

Detailed Error Reports that contain “333” (trading partner dispute) error code 000100 (duplicate

claim) or 000110 (duplicate ISA-IEA) or 000120 (duplicate ST-SE), all shared systems shall

automatically suppress generation of the special provider notification letters or reports/notifications,

as would normally be required in accordance with this section as well as §70.6.3 of this chapter.

NOTE: When suppressing their provider notification letters or reports/notifications for the foregoing

qualified situations, the A/B MACs and DME MACs shall also not update their claims histories to

reflect the non-crossing over of the associated claims. A/B MACs and DME MACs should,

however, continue to account for the volume of claims that they are suppressing for financial

reconciliation purposes.

Effective with October 6, 2008, when the BCRC returns the “222” error code “N22225” to A/B

MACs and DME MACs via the BCRC Detailed Error Report, the A/B MACs and DME MACs’

shared systems shall suppress generation of the special provider notification letters or

reports/notifications that they would normally issue in accordance with CRs 3709 and 5472.

When suppressing their provider notification letters or reports/notifications following their receipt of

a “N22225” error code, the A/B MACs’ and DME MACs’ shared systems shall also not update their

claims histories to reflect the non-crossing over of the associated claims. A/B MACs and DME

MACs should, however, continue to account for the volume of claims that they are suppressing for

financial reconciliation purposes.

Effective with January 5, 2009, when the BCRC returns claims on the BCRC Detailed Error Report

whose COBA ID falls in the range 89000 through 89999 (range designates “Other-Health Care Pre-payment Plan [HCPP] and HMO Cost Plan”), the A/B MACs’ and DME MACs’ systems shall take

the following actions:

1) Suppress generation of the special provider letters or reports/notifications; and

2) Not update their affiliated A/B MACs and DME MACs’ claims histories to indicate that the

BCRC will not be crossing the affected claims over.