100-04 Medicare Claims Processing Manual: Chapter 28 - Coordination With Medigap, Medicaid, and Other Complementary Insurers

Medicare Claims Processing Manual
Chapter 28 - Coordination With Medigap, Medicaid,
and Other Complementary Insurers
Table of Contents
(Rev. 13314; Issued:07-24-25)
Transmittals for Chapter 28
10 - Medigap - Definition and Scope
20 - Assignment of Claims and Transfer Policy
20.1 - Beneficiary Insurance Assignment Selection
30 - Completion of the Claim Form
30.1 - ASC X12 837 Professional/Form CMS-1500 COB
30.2 - ASC X12 837 Institutional/Form CMS 1450 COB
40 - MSN Messages
50 - Remittance Notice Messages
60 - Returned Medigap Notices
70 - Coordination of Medicare With Medigap and Other Complementary Health Insurance Policies
70.1 - Authorization for Release of Information
70.1.1 - Requests for Additional Information
70.1.2 - Release of Title XVIII Claims Information for Medigap Insurance Purposes by Providers
70.2 - Integration of Title XVIII Claims Processing With Complementary Insurance Claims Processing
70.2.1 - Program Recognition
70.2.2 - Records and Information
70.2.3 - Matching Files Against Medicare Claims Files
70.3 - Standard Medicare Charges for COB Records
70.4 - General Guidelines for A/B MAC (A, B, or HH) or DME MAC Transfer of Claims Information to
Medigap Insurers
70.5 - Audits
70.6 - Consolidation of the Claims Crossover Process
70.6.1 - Coordination of Benefits Agreement (COBA) Detailed Error Report Notification Process
70.6.1.1 - Coordination of Benefits Agreement (COBA) ASC X12 837 5010 Coordination of
Benefits (COB) Flat File Errors
70.6.2 - Coordination of Benefits Agreement (COBA) Full Claim File Repair Process

70.6.3 - Coordination of Benefits Agreement (COBA) Eligibility File Claims Recovery Process
70.6.4 - Coordination of Benefits Agreement (COBA) Medigap Claim-Based Crossover Process
70.6.5 - Coordination of Benefits Agreement (COBA) ASC X12 837 Coordination of Benefits
(COB) Mapping Requirements as of July 2012
70.6.6 - National Council for Prescription Drug Programs (NCPDP) Version D.0 Coordination of
Benefits (COB) Mapping Requirements
80 - Electronic Transmission - General Requirements
80.1 - Deleted - Reserved
80.2 - Deleted - Reserved
80.3 - Medigap Electronic Claims Transfer Agreements
80.3.1 - A/B MAC (A)/A/B MAC (HH) Crossover Claim Requirements
80.3.2 - A/B MAC/DME MAC Crossover Claim Requirements
90 - Deleted - Reserved
100 - Medigap Insurers Fraud Referral
110 - Medigap Criminal Penalties/Types of Complaints Under Section 1882(d)
110.1 - Outline of Complaint Referral Process
110.2 - Preliminary Screening and Referral to Regional Office of the Inspector General
110.3 - CMS Regional Office Quarterly Report on Medicare Supplemental Health Insurance Penalty
Provision Activity
110.3.1 - Statistics
110.3.2 - Narrative

10 - Medigap - Definition and Scope
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The Omnibus Budget Reconciliation Act of 1990 (OBRA 1990, Public Law 101-508) requires all Medicare
supplemental (Medigap) insurance policies to conform to minimum standards including loss ratio
requirements, standardized benefit packages and consumer protection requirements.
The procedures described in §§20 through 110 apply to all policies meeting the definition of Medicare
supplemental insurance policies (“Medigap”) in §1882(g)(1) of the Social Security Act (the Act.).
A Medigap policy is defined as: A group or individual policy of accident and sickness insurance, or a
subscriber contract of hospital and medical service associations or health maintenance organizations, other
than a policy issued pursuant to a contract under §1876 or §1833 of the Act, or a policy issued under a
demonstration project.
A Medigap policy is offered by a private company to those entitled to Medicare benefits and provides
payment for Medicare charges not payable because of the applicability of deductibles, coinsurance amounts
or other Medicare imposed limitations. Typically, a Medigap policy does not include limited benefit
coverage areas available to Medicare beneficiaries, such as “specified disease” or “hospital indemnity”
coverage. By law, the definition explicitly excludes a policy or plan offered by an employer to employees, or
former employees, as well as policies offered by a labor organization to members or former members.
The National Association of Insurance Commissioners has developed model regulatory language for State
insurance commissions to apply to Medigap insurance offerings. This model regulatory language is located
at: http://www.carfra.com/products/medsupappendixb.pdf. It recommends the requirements that states
should consider for approving proposed Medigap insurance plans.
The following procedures for furnishing information are mandatory for Medigap plans. Medicaid agencies
are furnished information in the standard format free of charge. Other commercial payers, including
Medigap insurers, must pay a CMS established per claim crossover fee for providing them with Medicare
paid claims data.
20 - Assignment of Claims and Transfer Policy
(Rev. 4069, Issued: 06-08 – 18, Effective: 07- 09- 18, Implementation: 07- 09-18)
A Medicare beneficiary who has a Medigap policy may authorize the participating physician/practitioner or
supplier of services to file a claim on his or her behalf and to receive payment directly from the insurer
instead of through the beneficiary. In such cases, Medicare must transfer Medicare claims information to
the Medigap insurer. The Medigap insurer pays the physician/provider/supplier directly. The Medigap
insurer, in turn, reimburses CMS’s designated COBA contractor for the costs in supplying the information
subject to limitations.
Paid claims from participating physicians or providers/suppliers for beneficiaries who have assigned their
right to payment under a Medigap policy, regardless of whether or not it is in or from a State with an
approved Medigap program, are to result in the transfer of claim information to the specified insurers.
The A/B MAC (Part B) and DME MAC systems must have the capability to distinguish between claims of
participating and nonparticipating physicians/practitioners and suppliers. This is because Medigap
assignment of claims and transfer policy does not apply to nonparticipating physicians/practitioners or non-
participating suppliers.

Effective with the future implementation of CMS’s consolidated Medigap claim-based crossover initiative,
the process for reporting Medigap information on incoming claims will change. Each Part B
physician/practitioner and supplier of durable medical equipment, prosthetics, orthotics, and medical
supplies (DMEPOS) will only include the CMS-issued Medigap claim-based COBA ID (ID range 55000
through 55999), which will be assigned by CMS’s Benefits Coordination & Recovery Center (BCRC), if: (1)
the physician/practitioner or supplier participates in the Medicare Program; and (2) the beneficiary has
assigned his/her rights to payment under a Medigap policy to that provider or supplier.
20.1 - Beneficiary Insurance Assignment Selection
(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.
Beneficiaries indicate that they have assigned their Medigap benefits to a participating physician/practitioner
or supplier by signing block #13 on the Form CMS-1500. This authorization is in addition to their
assignment of Medicare benefits as indicated by their signature in block #12.
Form CMS-1450 makes no provision for the provider to indicate that the beneficiary has assigned benefits
because the Form CMS-1450 is used only for institutional claims, for which payment is typically assigned to
the provider of services. For claims the institutional provider submits to A/B MACs (B) for physician
payments for physician employees; hospitals, SNFs, HHAs, OPTs, CORFs, or ESRD facilities may maintain
a beneficiary statement in file instead of submitting a separate statement with each claim. This authorization
must be insurer specific.
If the beneficiary has a Medigap policy, the following statement should be signed:
Beneficiary’s Medicare beneficiary
identifier
NAME OF BENEFICIARY 	MEDIGAP POLICY NUMBER
I request that payment of authorized Medigap benefits be made either to me or on my behalf to
_______________ for any services furnished me by that physician/provider/supplier. I authorize any holder
of medical information about me to release to (name of Medigap insurer) any information needed to
determine these benefits or the benefits payable for related services.
Since the beneficiary may selectively authorize Medigap assignments, caution providers about routinely
stamping item #13 of the Form CMS-1500 “signature on file.” The Medigap assignment on file in the
participating doctor/supplier’s office must be insurer specific. However, it may state that the authorization
applies to all occasions of services until it is revoked.
Effective with October 1, 2007, participating Part B physicians/practitioners and DMEPOS suppliers now
will only include the CMS-assigned Medigap claim-based COBA ID on an incoming claim if confirmation
that a beneficiary has authorized Medigap assignment has been obtained.
30 - Completion of the Claim Form
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
As part of the national Coordination of Benefits Agreement (COBA) claim-based Medigap crossover
process, participating physicians/practitioners and suppliers that are attempting to trigger mandatory

Medigap (“claim-based”) crossovers must include the CMS-assigned 5-digit Medigap COBA claim-based
ID (within range 55000 through 55999) within designated areas on the appropriate claim as follows:
• 	Within field NM109 of the NM1 segment within the 2330B loop of the incoming Health Insurance
Portability and Accountability Act (HIPAA) Accredited Standards Committee (ASC) X12- 837
professional claim (current format). [See §70.6.4 of this chapter for further information.]
• 	Item 9-D of the incoming paper Form CMS-1500 claim (NOTE: the PAYERID or the Medigap
company or plan name within this field will not trigger a Medigap claim-based crossover); and
In addition, unless otherwise specified, retail chain pharmacies that are attempting to trigger crossovers to
their clients’ Medigap insurers should enter the Medigap COBA claim-based within field 301-C1 of the T04
segment on the incoming National Council for Prescription Drug Programs (NCPDP) batch claims.
For more information regarding the COBA Medigap claim-based crossover process, refer to §70.6.4 of this
chapter.
30.1 - ASC X12 837 Professional/Form CMS-1500 COB
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Participating physicians/practitioners and suppliers sign an agreement with Medicare to accept assignment
of Medicare benefits for all Medicare patients. A claim for which a beneficiary elects to assign his/her
benefits under a Medigap policy to a participating physician/practitioner and supplier is called a “mandated
Medigap transfer.”
Participating providers and suppliers that must bill electronically shall enter the 5-digit claim-based Medigap
COBA ID in field NM109 of the NM1 segment in loop 2330B of the Health Insurance Portability and
Accountability Act (HIPAA) ASC X12 837 professional claim for purposes of triggering Medigap claim-
based crossovers. If a participating Part B physician/practitioner or DMEPOS supplier fails to include this
identifier in the field just described, the claim will not be transferred, as appropriate, to the Medigap insurer
via the COBA claim-based Medigap crossover process.
Under CMS’s national COBA claim-based Medigap process, participating Part B physicians/practitioners
and suppliers that are exempted under the Administrative Simplification Compliance Act (ASCA) from
having to bill electronically are required to enter the CMS-assigned 5-digit claim-based Medigap COBA ID
on the paper form.
Medigap information is entered on the CMS Form 1500 as follows:
Version 08/05
Item 9a - The policy and/or group number of the Medigap insured preceded by MEDIGAP, MG, or MGAP.
Note - item 9d must be completed if a policy and/or group number is entered in item 9a.
Item 9b - The Medigap insured’s 8-digit date of birth (MM|DD|CCYY) and sex.
Item 9c - Blank if item 9(d) is completed. Otherwise, the claims processing address of the Medigap insurer.
An abbreviated street address, two-letter postal code, and ZIP Code copied from the Medigap insured’s
Medigap identification card is entered. For example:
1257 Anywhere Street
Baltimore, Md. 21204
Is shown as
1257 Anywhere St. MD 21204

Item 9d - Enter the Coordination of Benefits Agreement (COBA) Medigap claim-based Identifier (ID).
Refer to chapter 28, section 70.6.4, of this manual for more information.”
All the information in items 9, 9a, 9 b, and 9d must be complete and accurate. Otherwise, the A/B MAC (B)
or DME MAC cannot forward the claim information.
Version 02/12
Item 9a - Enter the policy and/or group number of the Medigap insured preceded by MEDIGAP, MG, or
MGAP.
Note - item 9d must be completed if a policy and/or group number is entered in item 9a.
Item 9b - Leave blank.
Item 9c - Leave blank if item 9d is completed. Otherwise, enter the claims processing address of the
Medigap insurer. Use an abbreviated street address, two-letter postal code, and ZIP Code copied from the
Medigap insured’s Medigap identification card. For example:
1257 Anywhere Street
Baltimore, Md. 21204
Is shown as
1257 Anywhere St. MD 21204
Item 9d - Enter the Coordination of Benefits (COBA) Medigap claim-based identifier (ID). See Chapter 28,
§70.6.4 for more information.
All the information in items 9, 9a, and 9d must be complete and accurate. Otherwise, the A/B MAC (B) or
DME MAC cannot forward the claim information.
Retail pharmacies that wish to trigger claim-based crossovers to Medigap insurers shall enter the Medigap
claim-based COBA ID within field 301-C1 of the T04 segment of the NCPDP claim.
30.2 - ASC X12 837 Institutional/Form CMS-1450 COB
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
In accordance with the language provided within §1842(h)(3)(B) of the Social Security Act, no information
entered on an incoming Form CMS-1450 or incoming Health Insurance Portability Act (HIPAA) ASC X12
837 institutional claim (current format) shall result in a process whereby CMS transfers the claim to a
Medigap insurer.
40 - MSN Messages
(Rev. 4069, Issued: 06-08 – 18, Effective: 07- 09- 18, Implementation: 07- 09-18)
A Medicare beneficiary who has a Medigap policy may authorize the participating physician/practitioner or
supplier of services to file a claim on his or her behalf and to receive payment directly from the insurer
instead of through the beneficiary. In such cases, Medicare must transfer Medicare claims information to
the Medigap insurer. The Medigap insurer pays the physician/provider/supplier directly. The Medigap
insurer, in turn, reimburses CMS’s designated COBA contractor for the costs in supplying the information
subject to limitations.

Paid claims from participating physicians or providers/suppliers for beneficiaries who have assigned their
right to payment under a Medigap policy, regardless of whether or not it is in or from a State with an
approved Medigap program, are to result in the transfer of claim information to the specified insurers.
The A/B MAC (Part B) and DME MAC systems must have the capability to distinguish between claims of
participating and nonparticipating physicians/practitioners and suppliers. This is because Medigap
assignment of claims and transfer policy does not apply to nonparticipating physicians/practitioners or non-
participating suppliers.
Effective with the future implementation of CMS’s consolidated Medigap claim-based crossover initiative,
the process for reporting Medigap information on incoming claims will change. Each Part B
physician/practitioner and supplier of durable medical equipment, prosthetics, orthotics, and medical
supplies (DMEPOS) will only include the CMS-issued Medigap claim-based COBA ID (ID range 55000
through 55999), which will be assigned by CMS’s Benefits Coordination & Recovery Center (BCRC), if: (1)
the physician/practitioner or supplier participates in the Medicare Program; and (2) the beneficiary has
assigned his/her rights to payment under a Medigap policy to that provider or supplier.
50 - Remittance Notice Messages
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
All A/B MACs and DME MACs shall include the following message on remittance notices sent to
participating physicians/practitioners and suppliers when Medigap benefits are assigned and the information
in block #9 of the Form CMS-1500 (or FL50 of the Form CMS-1450, as appropriate) is completed:
MA 18 – “The claim information is also being forwarded to the patient’s supplemental insurer. Send any
questions regarding supplemental benefits to them.”
If the information in block #9 of the Form CMS-1500 or FL50 of the Form CMS-1450 is incomplete, or
more than one Medigap insurer was entered, MACs do not transmit a transaction record to the Medigap
insurer. In such cases, the following message is included on the remittance advices.
MA19 - “Information was not sent to the Medigap insurer due to incorrect/invalid information you
submitted concerning the insurer. Please verify your information and submit your secondary claim directly
to that insurer.”
Beginning with the October 2004 systems release, all A/B MACs and DME MACs 	shall include COBA
trading partner names on the provider Electronic Remittance Advice (ERA) following receipt of a
Beneficiary Other Insurance (BOI) reply trailer 29. (See §70.6 of this Chapter for more details.)
60 - Returned Medigap Notices
(Rev. 4069, Issued: 06-08–18, Effective: 07-09-18, Implementation: 07- 09-18)
A/B MACs (Part B) and DME MACs ceased this responsibility on October 1, 2007, when CMS’s BCRC
assumed full responsibility for the COBA claim-based Medigap process.
70 - Coordination of Medicare With Medigap and Other Complementary Health
Insurance Policies
(Rev. 4069, Issued: 06-08–18, Effective: 07-09-18, Implementation: 07-09-18)
For applicable policy on information sharing, see Pub 100-1, the Medicare General Information, Eligibility
and Entitlement Manual, Chapter 6.
For applicable cost sharing policy, see Pub 100-06, the Medicare Financial Management Manual, Chapter 1.

Cost Calculation Process Leading Up to the BCRC’s Assumption of Claim-Based Medigap Crossovers
Up to and including the final claims transferred under their pre-existing mandatory Medigap (claim-based)
crossover processes (note: the “final” claims should be those processed by the A/B MAC (Part B) or DME
MAC just before the October 2007 release is installed), A/B MACs (Part B) and DME MACs should
determine the frequency at which they routinely transmit notices to all Medigap insurers but must transmit
not less often than monthly. (See §70.4)
Effective October 1, 2005, CMS fully consolidated the eligibility file-based claims crossover process, as it
relates to Medigap insurers and other commercial payers, under the BCRC. Refer to §70.6 and succeeding
sub-sections for A/B MAC (Part B) and DME MAC requirements and responsibilities relating to the
national Coordination of Benefits Agreement (COBA) consolidated crossover process. Refer to §70.6.4 for
all MAC requirements relating to the COBA Medigap claim-based crossover process, which was
inaugurated on October 1, 2007. (See also Pub.100-04 chapter 27 §80.7.)
Following crossover consolidation, all A/B MACs (Part B) and DME MACs shall continue to pursue
collection of unpaid debts from Medigap insurers and other existing trading partners, even after such entities
have been transitioned to the COBA process. Those MACs that maintained claim-based crossover
arrangements with Medigap insurers shall pursue collection of their invoices up through and including their
invoices for the final claims transfer to the Medigap entities. These invoices should have been issued no
later than one (1) month following the last claims transfer to the Medigap insurers.
Suppression of Sanctioned Provider Claims from Claim-Based Medigap Crossovers
Effective with April 2, 2007, all A/B MACs (Part B) and DME MACs shall suppress fully denied provider
sanctioned claims for their mandatory Medigap crossover process with Medigap insurers, as authorized by
§1842(h)(3)(B) of the Social Security Act and §4081(a)(B) of the Omnibus Budget Reconciliation Act of
1987 [Public Law 100-230].
NOTE: All A/B MACs (Part B) and DME MACs shall continue to suppress 100 percent paid and 100
percent denied claims from their mandatory Medigap crossovers, per previous CMS guidance.
70.1 - Authorization for Release of Information
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual, Chapter 6.
70.1.1 - Requests for Additional Information
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
In the absence of a standing arrangement, the mere presence of an “authorization” to release and the
identification of a complementary insurer on a title XVIII billing form does not constitute a request for the
“release” of information. The request for the information must be specific.
70.1.2 - Release of Title XVIII Claims Information for Medigap Insurance Purposes by
Providers
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Subject to specific written beneficiary authorization, providers, physicians/practitioners, and suppliers are
permitted to furnish certain limited information about Medicare eligibility status and related claims
information to other payers for complementary insurance purposes. (See Chapter 6 of Pub 100-01, the
Medicare General Information, Eligibility, and Entitlement Manual.)

70.2 - Integration of Title XVIII Claims Processing With Complementary Insurance
Claims Processing
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
General
See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual for
instructions about disclosure of information.
See Chapter 1 of Pub. 100-06, the Medicare Financial Management Manual, for requirements for
determining costs.
70.2.1 - Program Recognition
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Since title XVIII program identity must be maintained, notices and forms for title XVIII purposes must
clearly identify their title XVIII origin. Also, they must not imply that title XVIII entitlement or enrollment
is dependent upon the individual’s retention of his/her complementary insurance policy.
70.2.2 - Records and Information
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 6, of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.
70.2.3 - Matching Files Against Medicare Claims Files
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.
70.3 - Standard Medicare Charges for COB Records
(Rev.4069, Issued: 06-08–18, Effective: 07-09-18, Implementation: 07-09-18)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.
The BCRC now has exclusive responsibility for the collection and reconciliation of crossover claim fees for
those Medigap and non-Medigap claims that A/B MACs and DME MACs send to the BCRC to be crossed
to trading partners.
70.4 - General Guidelines for A/B MAC (A, B, or HH) or DME MAC Transfer of
Claims Information to Medigap Insurers
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.
70.5 - Audits
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.

70.6 - Consolidation of the Claims Crossover 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.
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” by-
pass 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 23 rd 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.
70.6.1 - Coordination of Benefits Agreement (COBA) Detailed Error Report
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.
70.6.1.1 - Coordination of Benefits Agreement (COBA) ASC X12 837 5010
Coordination of Benefits (COB) Flat File Errors
(Rev. 3714, Issued: 02-03-17; Effective: 07-01-17; Implementation: 07-03-17)
Effective with the implementation of the Health Insurance Portability and Accountability Act (HIPAA) ASC
X12 837 5010 COB requirements, the BCRC will return the error codes shown in the chart below to all A/B
MACs and DME MACs whose flat file submissions lack structural elements necessary for the building of
outbound HIPAA compliant crossover claims.
The shared systems shall, in addition, make modifications to any “111” error tables that they maintain, in
accordance with the following charts, only in association with ASC X12 837 5010 COB flat files.

BCRC DETAILED ERROR REPORT “111” ERROR CRITERIA FOR 837 VERSION 5010
INSTITUTIONAL COB CLAIMS
Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
100 	No ST Segment 	NO 	NO 	NO 	NO 	NO 	YES 	NO 	NO 	NO 	HEAD
101 	No BHT Segment 	YES 	NO 	NO 	NO 	NO 	YES 	NO 	NO 	NO 	HEAD
103 	Missing 1000A
Records
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
104 	Missing 1000B
Records
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
105 	Invalid
1000A.NM109
YES 	NO 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
110 	Invalid
1000B.NM103
YES 	NO 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
115 	Invalid
1000B.NM109
YES 	YES 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
120 	Multiple 1000A per
ST/SE
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
125 	Multiple 1000B per
ST/SE
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
199 	All 2000B Rejected 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
200 	Missing 2000A 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
201 	Missing 2010AA 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
210 	Multiple 2010AA per
2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
211 	Multiple 2010AB per
2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
212 	Invalid presence of
2010AC per 2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
300 	Missing 2000B 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
301 	Missing 2010BA 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
302 	Missing 2010BB
Loop
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
305 	Multiple 2010BB per
2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
306 	Multiple 2010BA per
2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
310 	2010BB.NM109 not
equal 1000B.NM109
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
320 	2010BB.N3 not equal
spaces
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB
321 	2010BB.N4 not equal
spaces
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB
351 	More than 100 2300
per 2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
355 	2300 REF01 Equal
F5 Missing
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
356 	2300 HI Invalid 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
399 	All 2300 Loops
Rejected
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
400 	2010CA Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES
500 	2300 Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
505 	2320 Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
506 	# of 2320 Loops GT
10
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
507 	2320 OI Not Found 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
515 	2400 Not Found 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
520 	# of 2400 Loops GT
999
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
575 	2330A Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
576 	2330B Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
580 	2320.SBR01 not
equal P (must be at
least one “P”
segment)
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	CLM
581 	2320.SBR Field
Invalid (SBR09 does
not equal MB when
Medicare is primary
in SBR01)
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
590 	Multiple 2330A 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
591 	Multiple 2330B 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
595 	2330B.REF02 Equal 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
596 	2330B.NM109
Invalid COBA ID
(Not Used)
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
597 	2330B REF not
found
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
598 	2330B NM103 equals
spaces and invalid
COBA ID in 2330B
NM109
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
610 	# of 2430 Loops
greater than 15
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
620 	2430.SVD01 not
equal 1000A.NM109
YES 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	YES 	CLM
999 	SE Segment Missing 	YES 	YES 	NO 	NO 	NO 	YES 	NO 	NO 	YES 	HEAD

BCRC DETAILED ERROR REPORT “111” ERROR CRITERIA FOR PROFESSIONAL COB CLAIMS
Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
100 	No ST Segment 	NO 	NO 	NO 	NO 	NO 	YES 	NO 	NO 	NO 	HEAD
101 	No BHT Segment 	YES 	NO 	NO 	NO 	NO 	YES 	NO 	NO 	NO 	HEAD
103 	Missing 1000A
Records
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
104 	Missing 1000B
Records
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
105 	Invalid
1000A.NM109
YES 	NO 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
110 	Invalid
1000B.NM103
YES 	NO 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
115 	Invalid
1000B.NM109
YES 	YES 	NO 	NO 	YES 	YES 	YES 	YES 	YES 	HEAD
120 	Multiple 1000A per
ST/SE
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
125 	Multiple 1000B per
ST/SE
YES 	NO 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
199 	All 2000B Rejected 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	HEAD
200 	Missing 2000A 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
201 	Missing 2010AA 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
210 	Multiple 2010AA per
2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
211 	Multiple 2010AB per
2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
212 	Invalid presence of
2010AC per 2000A
YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	PROV
300 	Missing 2000B 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
301 	Missing 2010BA 	YES 	YES 	NO 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
302 	Missing 2010BB
Loop
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
305 	Multiple 2010BB per
2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
306 	Multiple 2010BA per
2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
310 	2010BB.NM109 not
equal 1000B.NM109
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB
320 	2010BB.N3 not equal
spaces
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
321 	2010BB.N4 not equal
spaces
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	SUB
351 	More than 100 2300
per 2000B
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
355 	2300 REF01 Equal
F5 Missing
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
356 	2300 HI Invalid 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
399 	All 2300 Loops
Rejected
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	SUB
400 	2010CA Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES
500 	2300 Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
505 	2320 Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
506 	# of 2320 Loops GT
10
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
507 	2320 OI Not Found 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
515 	2400 Not Found 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
520 	# of 2400 Loops GT
50
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
575 	2330A Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
576 	2330B Not Found 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
580 	2320.SBR01 not
Equal P (must be at
least one “P”
segment)
YES 	YES 	YES 	NO 	YES 	YES 	YES 	YES 	YES 	CLM
581 	2320.SBR Field
Invalid (SBR09 does
not equal MB when
Medicare is primary
in SBR01)
YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
590 	Multiple 2330A 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
591 	Multiple 2330B 	YES 	YES 	YES 	NO 	YES 	YES 	NO 	NO 	YES 	CLM
595 	2330B.REF02 Equal 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
596 	2330B.NM109
Invalid COBA ID
(Not Used)
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
597 	2330B REF not
found
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM
598 	2330B NM103 equals
spaces and invalid
COBA ID in 2330B
NM109
YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	YES 	CLM

Error
Code
Error Description 	Control
#
COBA
ID
Medicare
ID
CCN 	Loop
ID
Segment 	Element 	Content 	BHT
03
Reject
Level
610 	# of 2430 Loops
greater than 15
YES 	YES 	YES 	YES 	YES 	YES 	NO 	NO 	YES 	CLM
620 	2430.SVD01 not
equal 1000A.NM109
YES 	YES 	YES 	YES 	YES 	YES 	YES 	NO 	YES 	CLM
999 	SE Segment Missing 	YES 	YES 	NO 	NO 	NO 	YES 	NO 	NO 	YES 	HEAD

70.6.2 – Coordination of Benefits Agreement (COBA) Full Claim File Repair Process
(Rev. 4069, Issued: 06-08-18, Effective: 07-09- 8, Implementation: 07-09-18)
Effective with the July 2006 release, CMS implemented a full claim file repair process at its A/B MACs and
DME MACs to address situations where one or more of the MAC shared systems inadvertently introduced a
severe error condition into the claims processing cycle, with the effect being that the Health Insurance
Portability and Accountability Act (HIPAA) ASC X12 837 Coordination of Benefits (COB) Institutional
and Professional crossover claims files or National Council for Prescription Drug Programs (NCPDP) claim
files become unusable for COB purposes.
When an A/B MAC or DME MAC, the BCRC, or a COBA trading partner identifies a shared system
problem that will prevent, or has prevented, the COBA trading partner from accepting an ASC X12 837
COB institutional or professional claims file from the BCRC, the A/B MAC and DME MAC shall work with
its shared system maintainer to assess the feasibility of executing a full claim file repair. A/B MACs and
DME MACs shall utilize the BCRC Detailed Error Reports to determine the percentage of errors present for
each error source code—“111” (flat file) errors, “222” (ASC X12 837 COB) errors, and “333” (trading
partner dispute) errors. When A/B MACs and DME MACs or their shared system maintainers determine
that the error percentages are at or above the parameters discussed later within this section, the A/B MACs
and DME MACs shall begin the process of analyzing the claim files for a possible full claim repair process.
If the A/B MACs and DME MACs and their shared systems subsequently initiate a full claim file repair
process, that process shall be accomplished within a maximum of 14 work days, unless determined
otherwise by CMS.
Effective July 2, 2007, A/B MACs and DME 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 specified in §70.6.1 of this chapter. If an A/B MAC or
DME MAC receives even one (1) “111” error via the BCRC Detailed Error Report, the MAC, working with
its Data Center or shared system as necessary, shall immediately attempt a repair of the claims file, in
accordance with all other requirements communicated within this section.
1. A/B MAC or DME MAC or Shared System Identification of a Full Claim File Problem and
Subsequent Actions
When an A/B MAC or DME MAC, working with its shared system maintainer, identifies a severe error
condition that will negatively impact the claims that it has transmitted to the BCRC, the A/ B MAC or DME
MAC shall, upon detection, immediately notify CMS and the BCRC by calling current BCRC or CMS
COBA crossover contacts and sending e-mail communications to: COBAProcess@cms.hhs.gov and
cobva@ghimedicare.com.
The A/B MAC or DME MAC shall work closely with its system maintainer to determine the timeframes for
developing, testing, and applying a fix to correct the severe error(s) that was/were identified within the 837
or NCPDP files that were previously transmitted to the BCRC. The A/B MAC and DME MAC shared
system maintainers shall then report the timeframes for developing, testing, and applying a fix to the full
claim file problem in accordance with their procedures as outlined in their systems maintenance contract. If
CMS determines that the time frames for affecting a full claim file repair of the previously transmitted
claims exceed what is considered reasonable (a maximum of 14 work days, unless determined otherwise by
CMS), a designated COBA team representative will notify the A/B MACs and DME MACs and their shared
system maintainers via e-mail to abort the full claim file repair process. (NOTE: This process will remain
unchanged with the transition to future claim versions.)
Upon receipt of a notification from the CMS COBA team representative that indicates that the timeframes
for fixing a full claim file problem exceed those that are acceptable to CMS, the A/B MACs’ and DME
MACs’ shared systems shall abort the full claim file repair process. A/B MACs and DME MACs shall then

follow the requirements provided in §70.6.1 of this chapter with respect to the special provider notification
and other COBA crossover operational processes. In such cases, however, A/B MACs and DME MACs
shall not be required to wait the customary five (5) business days before generating the special provider
notification letters to their affected physicians, suppliers, or other providers of service.
2. Alerting A/B MACs or DME MACs to the Possible Need for a Full Claim File Repair via the BCRC
Detailed Error Reports and Subsequent MAC Actions
a. 	Severe Error Percentage Parameters and Suppression of the Special Provider Notification Letters
Effective with July 2006, the CMS, working in conjunction with the BCRC, modified the BCRC Detailed
Error Report layouts, as found in §70.6.1 of this chapter, to include the following new elements: Total
Number of Claims for Date of Receipt; Total Number of “111” (flat file) Errors and corresponding
percentage; Total Number of “222” (HIPAA ASC X12 837 COB) Errors and corresponding percentage;
and Total Number of “333” (trading partner dispute) Errors and corresponding percentage.
Effective with July 2007, CMS directed its A/B MACs and DME MACs to now base their severe error
decision calculus upon the number of “111” errors received rather than percentage of such errors.
Therefore, when an A/B MAC or DME MAC or its shared system maintainer receives a BCRC Detailed
Error Report that indicates that the trading partner is in production and the number of “111” (flat file)
errors is equal to or greater than one, the A/ B MAC’s and DME MAC’s shared system shall suppress
the generation of special provider notifications, as provided in § 70.6.1 of this chapter, until after the
severe error condition(s) has/have been analyzed. (NOTE: If the “222” and/or “333” errors indicated
on the BCRC Detailed Error Report do not exceed the four (4) percent parameter, then the A/B MAC
and DME MAC shall continue with the generation of the provider notification letters for those errors
while it is analyzing the “111” severe error(s).)
IMPORTANT: Effective October 1, 2007, A/B MACs and DME MACs and their systems shall have
the capability to initiate a claims repair process, internally or at CMS direction, for situations in which
they encounter high volume “222” or “333” error rejections that do not meet or exceed the established
error threshold parameters. Before initiating a claims repair for error situations that fall below the
established percentage parameters, the affected A/B MACs and DME MACs shall first contact a
member of the CMS COBA team to obtain clearance for that process.
When an A/B MAC or DME MAC or its shared system maintainer receives a BCRC Detailed Error
Report that indicates that the trading partner is in production and the percentage of “222” (HIPAA ASC
X12 837) errors and “333” (trading partner dispute) errors is equal to or greater than four (4) percent, the
shared system shall suppress the generation of special provider notifications, as provided in §70.6.1 of
this chapter, until after the severe error condition(s) has/have been analyzed. NOTE: If the number of
“111” errors indicated on the BCRC Detailed Error Report is not equal to or greater than one (1), then
the A/B MAC or DME MAC shall continue with the generation of the provider notification letters for
those errors while it is analyzing the “222” and “333” severe errors.
For each of the severe error situations discussed above, A/B MACs and DME MACs, or their shared
systems, shall suppress the special provider notification for a minimum of five (5) business days. The
shared systems shall also have the capability to adjust the parameters for generation of the provider
notification letters, as referenced in §70.6.1 of this chapter, of up to 14 work days while analysis of the
claims that are being “held” for possible full claim file repair is proceeding.
Effective October 1, 2007, all A/B MACs and DME MACs shall have the capability to suppress their
provider notification letters for a timeframe of up to 14 work days, or longer at CMS direction, where
they initiate a claims repair process when claims with “222” or “333” errors fall below the “normally
established” four (4) percent threshold.

Also, for each of the situations discussed above, the A/B MACs and DME MACs’ shared systems shall
establish percentage parameters for each error source code (222 and 333) that allow for flexibility within
a range (e.g., 1 to 10 percent).
b. 	Additional Information Highlighting Possible Severe Error Conditions on the BCRC Detailed
Error Reports.
Effective with July 2006, the BCRC will report one of the following error sources and error
codes/trading partner dispute codes that may be indicative of a severe error condition on the returned
BCRC Institutional and Professional Detailed Error Reports:
1.) 	Error source code “111” will be reported in field 10, along with a 6-digit error code in field
11 (note: unlike routine reporting of flat file errors, a full claim file error condition would be
indicated if there were numerous instances of the same error code repeated throughout a
Report); the description of the problem(s) that has/have caused the full claim file to be
unusable will be reported in field 12 (error description);
2.) 	Error source code “222” will be reported in field 10, along with a 6-digit error code in field
11 that begins with an “N”; the description of the problem(s) that has/have caused the full
claim file to be unusable will be reported in field 12 (error description);
3.) 	Error source code “333” will be reported in field 10; an error/trading partner dispute code
“999” (trading partner dispute—“other”) will be reported in field 11, left-justified and
followed by spaces; and a description of the problem(s) that has/have caused the full claim
file to be unusable will be reported in field 12 (error description).
DME MACs and their shared systems shall process NCPDP Detailed Error Reports returned from the
BCRC that contain the following combination of error source codes, error/trading partner dispute codes,
and error descriptions within the Reports:
1.) 	Error source code “111” will be reported in field 9, along with a 6-digit error code in field 10
(NOTE: Unlike routine reporting of flat file errors, a full claim file error condition would be
indicated if there were numerous instances of the same error code repeated throughout a
Report); and a description of the problem(s) that has/have caused the full claim file to be
unusable will be reported in field 11; or
2.) 	Error source code “333” will be reported in field 9; an error/trading partner dispute code
“999” will be reported in field 10, left-justified and followed by spaces; and a description of
the problem(s) that has/have caused the full claim file to be unusable will be reported in field
11 (error description).
c. 	A/B MAC and DME MAC Actions Following Suppression of the Special Provider Notification
Letters to Analyze Possible Severe Error Conditions
When A/B MACs and DME MACs receive BCRC Detailed Error Reports that contain “222” or “333”
errors with percentages that are at or above the established parameters—or if the MACs receive “111”
errors that are at or above zero (“0”)—they shall work closely with their shared system maintainers to
determine the timeframes for developing, testing, and applying a fix to correct the severe error(s) that
was/were identified within the ASC X12 837 or NCPDP files that were previously transmitted to the
BCRC. The shared system maintainers shall then report the timeframes for developing, testing, and
applying a fix to the full claim file problem in accordance with their procedures as outlined in their
systems maintenance contract. If CMS determines that the timeframes for affecting a full claim file
repair of the previously transmitted claims exceed what is considered reasonable (a maximum of 14

work days, unless determined otherwise by CMS), a designated COBA team representative will notify
the A/B MACs and DME MACs and their shared system maintainers via e-mail to abort the full claim
file repair process.
As noted above, effective October 1, 2007, all A/B MACs and DME MACs shall have the capability to
suppress their provider notification letters for a timeframe of up to 14 work days, or longer at CMS
direction, where they initiate a claims repair process when claims with “222” or “333” errors fall below
the “normally established” four (4) percent threshold.
Upon receipt of a notification from the CMS COBA team representative that indicates that the
timeframes for fixing a full claim file problem exceed those that are acceptable to CMS, the A/B MACs
and DME MACs’ shared systems shall abort the full claim file repair process. A/B MACs and DME
MACs shall then follow the requirements provided in §70.6.1 of this chapter with respect to the special
provider notification and other COBA crossover operational processes. In such cases, however, A/B
MACs and DME MACs shall not be required to wait the customary five (5) business days before
generating the special provider notification letters to their affected physicians/practitioners, suppliers, or
other providers of service.
In the event that CMS indicates that a full claim file repair process is feasible, the A/B MACs and DME
MACs’ shared systems shall have the ability to cancel the generation of the provider notification letters,
as stipulated in §70.6.1 of this chapter, for the “repaired” claims and only generate the provider
notification letters for the claims containing legitimate 111, 222, or 333 errors not connected with the
severe error condition(s).
3. Steps for Ensuring that Only “Repaired” Claims are Re-transmitted to the BCRC
Once the A/B MACs and DME MACs’ shared systems have determined that they are able to affect a
“timely” repair to the full claim files that were previously transmitted to the BCRC, they shall take the
following actions:
a) 	Apply the fix to the unusable claims;
b) 	Compare the claims files previously sent to the BCRC with the repaired claims file to isolate the
claims that previously did not contain the error condition(s);
c) 	Strip off the claims that did not contain the error condition(s), including claims that contained 111,
222, and 333 errors that were not connected with the severe error condition(s). For the latter set of
claims (those with 111, 222, and 333 errors that were not connected to the severe error condition),
MACs shall then generate the provider notification letters, as stipulated in §70.6.1 of this chapter and
specified in the concluding paragraph of the above sub-section entitled, “Contractor Actions
Following Suppression of the Special Provider Notification Letters to Analyze Possible Severe Error
Conditions”;
d) 	Recreate the job; and
e) 	Send only the “repaired” claims to the BCRC.
The shared systems shall add an indicator”18” to the BHT02 (Beginning of the Hierarchical
Transaction/Transaction Set Purpose Code) segment of the HIPAA ASC X12 837 flat file to designate that
the file contains only repaired claims. In addition, the shared systems shall include the repaired claims in
different ST-SE envelopes to differentiate the repaired claims from normal ASC X12 837 flat file
transmissions.

The DME MAC shared system shall add an indicator “R” after the COBA ID reported in the Batch Header
Record in the Receiver ID field (field number 880-K7) of the NCPDP claim when transmitting the repaired
claims to the BCRC.
4. COBA Repair Process Changes Effective with July 2012
A. 	Repairing Flat File (“111”) Errors
All A/B MACs and DME MACs shall effectuate repair of even one “111” errored COB claim if the COBA
trading partner is currently in “production” mode. (NOTE: Parties interested in previewing a listing of all
“111” errors that the BCRC will apply to incoming COB flat files should refer to §70.6.1.1 of this chapter.)
The shared systems shall accept the “111” error codes (see §70.6.1.1 of this chapter) that the BCRC
generates during its application of business level editing to incoming ASC X12 837 COB flat files. The
shared systems shall also make modifications to any “111” error tables that they maintain only in association
with ASC X12 837 COB flat files.
IMPORTANT: A/B MACs and DME MACs shall only issue special provider notification letters in
association with their receipt of “111” errors if: 1) the timeframe for effectuating a claims repair falls
outside acceptable parameters (e.g., will take 30-60 days or longer); and 2) the volume of affected claims is
low (i.e., under 1,000 claims per week). A/B MAC and DME MAC crossover contacts should contact a
member of the CMS COBA team if they have questions regarding how they should proceed in association
with a given “111” error situation.
B. 	Repairing “222” and “333” Errors Associated With “Production” New Version Format Claims
A/B MACs and DME MACs and their shared systems shall repair “222” or “333” errors in association with
“production” new format version claims if the error percentage they encounter meets or exceeds four (4)
percent.
A/B MACs and DME MACs shall alert their shared system or Data Center, as per established protocol, for
purposes of initiating each needed claims repair process in association with new format version COB claims.
IMPORTANT: A/B MACs and DME MACs that wish to effectuate a repair of new format version
“production” claims whose error percentage falls below four (4) percent shall contact a member of the CMS
COBA team before attempting that action. (NOTE: As a rule, CMS will grant approval for such a repair if
the volume of errored claims justifies that action and if the timeframe for repair is acceptable.)
In accordance with §70.6.1 of this chapter, A/B MACs and DME MACs shall issue special provider
notification letters in those instances where 1) error percentages for “222” and “333” errors fall below four
(4) percent; 2) the volume of errors on “production” new format version COB is not substantial enough to
cause the A/B MAC or DME MAC to request a claims repair; or 3) the timeframes for claim repair, as
determined by the associated shared system, are not acceptable to CMS.
C. 	Generally Applicable Requirements
While A/B MACs and DME MACs are not expected to initiate the repair of “test” claims, they shall: 1)
continue to monitor the BCRC Detailed Error Reports; and 2) notify their shared systems of errors returned
so that necessary shared system changes to improve HIPAA compliance rates may be realized.
D. 	New Date Parameter Logic and Cutover Claims Repair Requirements
To ensure appropriate cutover to the HIPAA ASC X12 COB flat file format, all shared systems shall
develop new date parameter logic to become operational as of January 1, 2012. All shared systems shall
ensure that the new logic addresses all of the following scenarios: repairing any errored old format claims in
the current claim format; converting claims held in suspense from an old format to the current claim format;

converting previously adjudicated old format claims to the current ”skinny” non-SFR COB claim format in
adjustment claim situations; and converting claims held in “provider alert status” from an earlier) format to
the current “skinny’ non-SFR COB claim format.
For claims repair scenarios involving claims previously sent to the BCRC in the prior format just prior to
January 1, 2012, the shared systems shall retransmit repaired claims to the BCRC in the current format. To
that end, all shared systems shall utilize CMS-issued mapping and gap-filling guidance provided in chapter
24 §40.4 and chapter 28 §70.6.5 of Pub.100-04 when repairing their originally transmitted prior format
errored crossover claims in the HIPAA current ASC X12 837 claim format on and after January 1, 2012. In
addition, the shared systems shall apply current non-SFR “skinny” logic to claim repair situations where
they originally transmitted claims to the BCRC prior to January 1, 2012 in the prior claim format.
IMPORTANT: A/B MACs and DME MACs shall not repair errored claims in a prior format that they
transmitted to the BCRC just prior to January 1, 2012 if the errors returned via the BCRC Detailed Error
Report relate to a field or segment that no longer exists in the current claim format. Instead, A/B MACs and
DME MACs shall issue provider notification letters for those errored claims to the affected providers.
70.6.3 - Coordination of Benefits Agreement (COBA) Eligibility File Claims Recovery
Process
(Rev. 10638; Issued: 03-09-21; Effective: 04-05-21; Implementation: 04-05-21)
Effective January 2, 2007, when the CMS or the BCRC determines that 1) certain members on a COBA
production trading partner’s eligibility file were not properly loaded to the Common Working File (CWF)
Beneficiary Other Insurance (BOI) auxiliary file (see §70.6 of this chapter for more details regarding this
file) or 2) a COBA production trading partner’s claims selections, as conveyed via the COBA Insurance File
(COIF), were not properly loaded to the CWF, the CMS shall send the A/B MAC crossover contact(s) and
associated Virtual Data Center (VDC) a ‘COBAProcess’ e-mail communication. When the CMS sends a
“COBAProcess” e-mail communication to an A/B MAC to initiate a COBA eligibility file claims recovery
process, the A/ B MAC shall acknowledge receipt of the communication via return e-mail within 1 business
day. The CMS will then contact the A/B MAC’s crossover staff and associated VDC either via phone or e-
mail to discuss the specific Common Working File (CWF) date span (i.e., process date) or claim date of
service parameters, or both, for the claims recovery process. Additionally, CMS will specify which specific
MAC(s), by state, will be involved in the COBA claims recovery activity. (NOTE: DME MACs and their
shared system may be required to implement the COBA eligibility file claims recovery process as part of a
future instruction.)
Following the telephone discussion between the CMS and the A/B MAC crossover staff, the COBA
eligibility file recovery process will further unfold as detailed below.
1. 	Receipt and Processing of the BCRC COBA Eligibility File and Searching Claims History for the
Needed Claims
Until April 5, 2021, as part of an active COBA claims recovery, the two VDCs that support the A/B MACs
shall complete an Electronic Transmittal Form (See Attachment A at the conclusion of this section) on behalf
of their associated MACs that are participating in a COBA claims recovery process. (Note: The COBA E01
eligibility file contains specifications on the COBA trading partner and the individuals whose claims need to
be recovered.)
Effective April 5, 2021, the VDCs shall be prepared to accept the following modified dataset names for the
COBA E01 Eligibility File as received from the CMS BDC:

Perspecta VDC Part A Recovery E01 Eligibility File: ASH0.FISP.HBADR.GHI.FSSFCOBE(+1)
Perspecta VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)
Companion Data Services (CDS) VDC Part A Recovery E01 Eligibility File:
ASP2.FISP.NDM.FSSFCOBE(+1)
CDS VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)
Through the COBA claims recovery process, the COB&R system supporting the BCRC sends the appropriate
VDC a copy of the trading partner’s COBA eligibility file(s), which will be prepared in accordance with the
CMS proprietary format. (Note: The COB&R system supporting the BCRC will transmit the COBA
eligibility file to the VDC through its existing Connect: Direct connection.) The VDC then notifies the
affected A/B MAC(s) that the COBA recovery eligibility file is available so that the A/B MAC(s) may
initiate a claims recovery.
Effective April 1, 2019, the shared systems supporting the A/B MACs shall accept either a Health Insurance
Claim Number (HICN) or Medicare Beneficiary Identifier (MBI), as reported via the COBA E01 eligibility
file, in the field defined as “Beneficiary Medicare ID” (file displacement 64—75).
The A/B MAC shall initiate recovery of the processed claims by systematically going against its online
claims history that meet the beneficiaries’ eligibility dates, as provided on the BCRC eligibility file(s), and
that fall within the specified CWF date span (i.e., process date) or date of service parameters, or both, that
CMS has provided to the A/B MAC.
In performing the COBA claims recovery, MACs shall not attempt to recover claims that were previously
transmitted to the BCRC. "Previously transmitted claims" may be identified by the claims' crossover
location status or the presence of the COBA ID being used for the recovery process along with a "P"
(production) indicator in association with the processed claims.
Additionally, the MAC shall not apply the COBA trading partner's selection criteria, as found on the Health
Insurance Master Record (HIMR) COBS, when recovering claims.
2. 	Time Frames for Recovery
The A/B MAC shall complete its claims recovery process, culminating with transmission of the recovered
claims to the COB&R system supporting the BCRC, within eight (8) work days following the date that it
receives the BCRC COBA eligibility file or as soon as possible thereafter as CMS directs.
3. 	Using Data Elements from the COBA Eligibility File For the Claims Recovery Process and
Copying Elements from That File to the Recovered Claims Flat File
A/ B MACs shall perform the following activities related to the COBA eligibility file:
a) 	Utilize each beneficiary’s coverage dates from the COBA eligibility files (file
displacement 121—128 for beneficiary supplemental eligibility-from date and file
displacement 129—136 for beneficiary supplemental-to date); and successive eligibility-
from and eligibility-to dates if provided);
b) 	Apply the specified CWF date span; or
c) 	Apply the date of service parameters; or
d) 	Both items b and c above.

Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy
the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B
loop of the flat file containing the recovered Part A and B claims.
4. 	Using Data Elements from the COBA Eligibility File For the Claims Recovery Process and
Copying Elements from That File to the Recovered Claims Flat File
A/ B MACs shall perform the following activities related to the COBA eligibility file:
e) 	Utilize each beneficiary’s coverage dates from the COBA eligibility files (file
displacement 121—128 for beneficiary supplemental eligibility-from date and file
displacement 129—136 for beneficiary supplemental-to date); and successive eligibility-
from and eligibility-to dates if provided);
f) 	Apply the specified CWF date span; or
g) 	Apply the date of service parameters; or
h) 	Both items b and c above.
Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy
the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B
loop of the flat file containing the recovered Part A and B claims.
4. 	Scope of the Claims Recovery Effort
Neither the A/B MAC nor its VDC shall be required to search archived claims history while fulfilling the
COBA eligibility file claims recovery process.
The A/ B MAC and its VDC shall not be required to apply the COBA production trading partner’s selection
criteria before transmitting the recovered claims to the BCRC.
The A/B MAC or its VDC shall not transmit claims that had previously been sent to the BCRC as part of the
COBA eligibility file claims recovery process, as demonstrated by the claims’ crossover location status or
the presence of a COBA identification (ID) number accompanied by a ‘P’ (production) indicator in relation
to the processed claims.
5. 	Populating a Unique BHT-03 Identifier to Designate Recovered Claims
The A/ B MAC shared systems shall be required to populate an ‘R’ indicator in the 22 nd position of the
Beginning of the Hierarchical Transaction (BHT)-03 segment of the ASC X12 837 flat file when
transmitting recovered claims for COBA production trading partners to the BCRC. (NOTE: The CMS
would only consider invoking the COBA eligibility file recovery process for trading partners that are in
production mode. Therefore, this practice does not conflict with previous guidance issued by the CMS,
which may be referenced in §70.6.1 of this chapter.)
6. 	Preparation and Transmission Requirements
The recovered claim files shall be prepared in the same ASC X12 837 flat file format used for normal, daily
transmissions to the COB&R system in support of BCRC, as discussed in §70.6 of this chapter.

Effective April 5, 2021, in transmitting the recovered claims to the CMS BDC (which, in turn, transmits the
files to the COB&R system in support of the BCRC), the VDCs shall transmit the claims via a separate ASC
X12 837 flat file transmission using the modified EFT dataset names shown below.
• P/T#EFT.ON.COBA.PA.Cxxxxx.RCV.Dyymmdd.Thhmmsst 	[For 837 Institutional Claims]
• P/T#EFT.ON.COBA.PB.Cxxxxx.RCV.Dyymmdd.Thhmmsst [For 837 non-DMEPOS Professional
Claims]
Note the following definitions apply to the dataset names above:
• 	P/T – “P” = Production; “T”=Test
• 	Cxxxxx = C + the 5-digit MAC ID; e.g, C12302
• 	Dyymmdd.Thhmmsst = Current date and Time concatenated to literals D and T.
The VDCs shall send no more than 100,000 recovered claims (which equates to 20 ST-SE envelopes per
A/B MAC with 5,000 claims per envelope) to the COB&R system supporting the BCRC per transmission.
7. Marking Claims History To Assist Customer Service Efforts
When the VDC transmits the recovered claims to the COB&R system supporting the BCRC, the A/B MAC
shall mark its claims history to indicate that each claim was recovered and transmitted to the BCRC to be
crossed over to the COBA trading partner.
A/B MACs shall notify their customer service representatives that they will be able to determine that
recovered claims were sent to the BCRC by referencing claims history.
8. 	BCRC Detailed Error Report Processes In Relation to the Claims Recovery Process
If A/B MACs receive BCRC Detailed Error Reports that contain a 22-byte BHT-03 identifier that ends with
an ‘R,’ they shall suppress generation of provider letters, regardless of the error source code indicated
(‘111,’ ‘222,’ or ‘333’).
When the A/B MAC, or its shared system, receives BCRC Detailed Error Reports for recovered BCRC
Detailed Error Reports for recovered claims that contain ‘111,’ ‘222,’ or ‘333’ errors, it shall mark its claims
history to indicate that the recovered claims will not be crossed over.
9. 	The Possibility of Repairing COBA Recovery Claims
A/B MACs, and their shared systems, shall assume that recovered claims for COBA production trading
partners that exceed established percentage parameters for ‘111,’ ‘222,’ and ‘333’ errors are potential
candidates for the COBA repair process, as provided in §70.6.2 of this chapter.
In accordance with the full claim file repair process discussed in 70.6.2 of this chapter, A/B MACs and their
shared systems shall populate an ‘18’ Beginning of the Hierarchical Transmission (BHT)-02 transaction set
purpose code at the ST-SE envelope level when transmitting the ‘repaired’ COBA recovery claims.
Unlike the process documented in §70.6.2 of this chapter, A/B MACs shall transmit ‘repaired’ COBA
recovery claims to the COB&R system supporting the BCRC via the separate ASC X12 837 flat file
transmission for recovery claims, as described within "Preparation and Transmission Requirements” above.

In addition, unlike the existing full claim file recovery process documented in §70.6. 2 of this chapter, A/B
MACs and their shared systems shall include an ‘R’ in the 22 nd position of the BHT-03 identifier when
transmitting the ‘repaired’ COBA recovery claims to the COB&R system supporting the BCRC.
A/B MACs, or their shared systems, shall also not generate provider notification letters if they, in
conjunction with CMS, determine that the recovered claims that contained severe errors cannot be repaired.
10. 	COBA Claims Recovery Financial Management Processes
The CMS will reimburse the A/B MAC for individual claims accepted by the trading partner at the current
per claim rate.
The A/B MACs’ shared systems shall develop a separate report for their associated A/B MACs to enable
them to fulfill the foregoing requirements. The shared systems shall create reports that will provide MACs
with the count of recovered claims per cycle.
Attachments A and B Relating to the COBA Claims Recovery Process
Special note: With the modernization of the Electronic Files Transfer (EFT) process used for COBA, the
A/B MACs and their associated VDCs will no longer need to complete the Electronic Transmittal Form
(Attachment) A, as included below, prior to initiating a COBA claims recovery process effective April 5,
2021.

Attachment A
ELECTRONIC TRANSMITTAL FORM
Project: 	Coordination of Benefits Agreement (COBA)
Task: 	COBA Claims Recovery Process
Contact Information
Company Name: __________________________
Contact Name: ______________________________ Phone# ___________ ext. _
Contact Email Address: ______________________________________________
CMSNet Information
Account ID:___________________ Node ID: ________________
IP Address: ___________________ Port: ____________________
Production Requirements
Filename(s): _______________________________________________________
Special Instructions (e.g., file triggers):
Test Requirements
Filename(s):
Special Instructions (e.g., file triggers):

Attachment B
COBA Eligibility File
Table 1: COBA Eligibility E01 Record Layout Header – E00
Data Element 	Description 	Field
Length
MO 	Field
Location
HEADER RECORD
TYPE
Value -E00 	3X 	O 	E00.001
HEADER COBA ID 	COBA ID assigned by the COBC
Field is 9 position, alphanumeric (no
special characters), left justified, last
four positions are spaces.
Mandatory.
9X 	O 	E00.002
HEADER CREATION
DATE
Date the record was created; format:
(CCYYMMDD), with no special
characters
8X 	O 	E00.003
HEADER BENEFICIARY
STATE CODE
Beneficiary State of residence
NOTE: This field will not be
used by the COBA Process.
2X 	O 	E00.004
FILLER 	Blank Field. Value is spaces. 	178X 	O 	E00.005
Table 2: COBA Eligibility E01 Record Layout
File attributes:
Format: Fixed block
Length: 200 bytes
Data Field 	Length 	Type 	Displacement 	Description
Record type 	3 	Alpha-Numeric 	1–3 	Type of Record Set to ‘E01’.
Mandatory
COBA ID 	9 	Alpha-Numeric 	4-12 	Coordination of Benefits
Agreement Identification
Number Field is 9 position,
alphanumeric (no special
characters), left justified, last
four positions are spaces.
Mandatory
File Effective Date 	8 	Alpha-Numeric 	13-20 	Effective date of file in
CCYYMMDD format with no
special characters.
Mandatory

Data Field 	Length 	Type 	Displacement 	Description
File Update Indicator 	1 	Alpha-Numeric 	21 	Type of update values:
‘A’ = Add
‘C’ = Change/Update
‘D’ = Delete
Required as of March
1, 2007
*Beneficiary Surname 	20 	Alpha-Numeric 	22-41 	Beneficiary last name
Mandatory
Uppercase characters only
*Beneficiary First 	12 	Alpha-Numeric 	42-53 	Beneficiary first name.
Mandatory
Uppercase characters only
Beneficiary Middle
Initial
1 	Alpha-Numeric 	54 	Beneficiary middle initial.
Optional
Uppercase characters only
*Beneficiary Birth Date 	8 	Alpha-Numeric 	55-62 	Beneficiary date of birth in
CCYYMMDD format with no
special characters.
Mandatory
*Beneficiary Sex Code 	1 	Alpha-Numeric 	63 	Beneficiary sex code values
are: ‘M’ = Male ‘F’ = Female
NOTE: If unknown, default to
‘M’
Mandatory
Uppercase characters only
Beneficiary Medicare
ID
12 	Alpha-Numeric 	64-75 	Beneficiary Medicare ID
(Medicare Health Insurance
Claim Number [HICN] or
Medicare Beneficiary
Identifier [MBI]).
Mandatory
Beneficiary
Supplemental ID
Number
25 	Alpha-Numeric 	76-100 	Supplemental ID on file with
sender. Should be the same
as what is submitted on the
claim.
Optional
Beneficiary Group
Policy Number
20 	Alpha-Numeric 	101-120 	Supplemental policy number
on file. Should be the same as
what is submitted on the claim.
Optional

Beneficiary
Supplemental Eligibility
From Date-1
8 	Alpha-Numeric 	121-128 	Medicare supplemental
“from” date in CCYYMMDD
format with no special
characters.
Mandatory
Data Field 	Length 	Type 	Displacement 	Description
Beneficiary
Supplemental
Eligibility To Date-1
8 	Alpha-Numeric 	129-136 	Medicare supplemental “to”
date in CCYYMMDD
format with no special
characters NOTE: This is
the coverage through
date. Indicate zeros for
open-ended dates.
Mandatory
Filler 	64 	Alpha- Numeric 	137-200 Unused Field – Populate
with spaces
Table 3: COBA Eligibility E01 Record Layout Trailer Record – E99
Data Element 	Description 	Field
Length
MO 	Field
Location
Record Type 	Value is 'E99'. 	3X 	M 	E99.001
E01 Record Count 	Total number of E01 records in this file. 	7N 	M 	E99.002
Filler 	Blank Field – Value is spaces 	190X 	M 	E99.003

70.6.5 - Coordination of Benefits Agreement (COBA) ASC X12 837
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).
2 nd 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).
2 nd 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.
70.6.6 - National Council for Prescription Drug Programs (NCPDP)
Version D.0 Coordination of Benefits (COB) Requirements
(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 - BASIC REQUIREMENTS
Prior to the mandatory cut-over to the NCPDP new batch telecommunications claim
version, the DME MAC shared system shall develop a current, in-use format “skinny”
non-SFR claim format to accommodate those situations where COBA trading partners
are unable to accept pharmacy-submitted claims in the NCPDP new version format. In
addition, the DME MAC shared system shall develop an NCPDP new version “skinny”
non-SFR format that addresses the scenario of claims originally adjudicated in the

NCPDP current, in-use format and later adjusted after the NCPDP new version format is
required in association with all incoming and outgoing NCPDP new version claims.
The DME MAC shared system shall also develop an NCPDP new version “skinny” non-
SFR format that addresses the scenario of claims that a DME MAC originally adjudicated
in the NCPDP current, in-use format but suspended for a period of time that meets or
transcends the date by which the NCPDP new version format is required in association
with all incoming and outgoing NCPDP new version claims.
II - NCPDP New Version Mapping Requirements
With respect to the NCPDP new version COB flat file submissions to the Benefits
Coordination & Recovery Center (BCRC), the ViPS Medicare System (VMS) maintainer
shall observe the following business rules for mapping:
A. 	General
1. 	The 504-F4 (“Message”) Trailer portion of the file shall contain a 22-byte
identifier populated as follows:
a.) Bytes 1-9—Contractor ID (9 bytes; DME MAC ID, or, 5 bytes left justified,
followed by spaces);
b.) Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);
c.) Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should
increment for each ST-SE envelope);
d.) Bytes 20-21—Claim Version Indicator (2 bytes; values= 20 for NCPDP
version D.0 claims); and
e.) Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test; “P”—
production).
B. 	Transmission/Transaction Header Segment
1. 	Create 101-A1 (“BIN assigned number”) with spaces.
2. 	Create the claim version release number (102-A2) within the
Transmission/Transaction Header Segment.
3. 	Populate the appropriate transaction code (103-A3), the processor control
number (104-A1), and transaction count value (109-A9).
4. 	Always map the service provider ID qualifier corresponding to the national
provider identifier (NPI) in 202-B2.

5. 	Always map the supplier’s NPI in 201-B1 (“Service Provider ID”).
6. 	Map date of service from incoming claim for 401-D1.
7. 	Map 110-AK (“Software Vendor/Certification ID”) from incoming claim.
IMPORTANT: 	For “skinny” NCPDP current, in use claim scenarios,
where the incoming claim is the current, in use version NCPDP, the shared
system shall map “unknown” in 110-AK.
C. Transmission Insurance Segment
1. 	Map the beneficiary’s Medicare beneficiary identifier in 302-C2 (“Cardholder
ID”).
2. 	Map 312-CC and 313-CD (“Cardholder’s First and Last Names”) using
information from the DME MAC’s internal eligibility file.
3. 	Do not create 301-C1 (“Group ID”), as CMS no longer authorizes claims-based
transfers to Medicaid State Agencies.
4. 	Do not create 336-8C (“Facility ID”), even in “skinny” claim situations.
5. 	For Medigap claim-based crossover purposes only, the shared system shall
continue to populate the Medigap claim-based COBA ID (range 55000-55999)
in the flat file field corresponding to 301-C1 (Group ID), as derived from the
incoming claim.
In addition, the shared system shall populate the Medigap policy ID in the
newly created 359-2A (Medigap ID) element, as derived from the incoming
claim.
6. 	Always map an “A” value for element 361-2D (“Provider Accept Assignment
Indicator”).
7. 	Do not create elements 115-N5, 116-N6, 314-CE, 303-C3, and 306-C6.
8. 	Create 524-F0 (“Plan ID”) in the future only when CMS directs.
D. 	Transmission Patient Segment
1. 	Create element 331-CX (“Patient ID Qualifier”) as appropriate.
2. 	Create 307-C7 (“Place of Service”) based upon the incoming claim.

3. 	Always map the beneficiary’s Medicare beneficiary identifier in 332-CY
(“Patient ID”).
4. 	Map elements 304-C4, 305-C5, 310-CA, and 311-CB from the DME MAC’s
internal beneficiary eligibility file.
5. 	Map elements 322-CM, 323-CN, 324-CO, and 325-CP from the DME MAC’s
internal beneficiary eligibility file. 	(*--See Gap Filling Requirements in
Attachment B to address situations where the beneficiary’s line-1 address, as
derived from the DME MAC’s internal beneficiary eligibility file, is blank or
incomplete.)
6. 	Map 326-CQ (“Patient Phone Number”) and 350-HN (“Patient E-mail
Address”) from incoming claim. (Assumption: CEDI will ensure these values
are syntactically correct as a condition of inbound claim acceptance.)
7. 	Do not create element 335-2C (“Pregnancy Indicator”) on the NCPDP new
version COB file.
E. 	Transaction Prescriber Segment
1. 	Map element 466-EZ (“Prescriber ID Qualifier”) from the incoming claim.
2. 	Always map “01” for element 468-2E (“Primary Care Provider ID Qualifier”).
3. 	Map the NPI, as derived from the incoming claim, in element 421-DL
(“Primary Care Provider ID”).
4. 	Map the supplier’s name, as derived from the DME MAC’s internal provider
files, for 470-4E (“Primary Care Provider Last Name”).
5. 	Map 411-DB based upon adjudicated claim data.
6. 	Map 427-DR (“Prescriber Last Name”) and 364-2J (“Prescriber First Name”)
from the DME MAC’s internal supplier files.
7. 	Map 365-2K (“Prescriber Address”), 366-2M (“Prescriber City”), 367-2N
(“Prescriber State”), 368-2P (“Prescriber Zip”), and 498-PM (“Prescriber Phone
Number”) based upon the availability of these elements in the SFR. (See
Attachment B for special gap-filling requirements that will come into play for
NCPDP skinny mapping.)
F. 	Transaction COB/Other Payments Segment
1. 	Map element 337-4C from the incoming claim.

2. 	Prepare element 338-5C to appropriately qualify deductible or co-insurance
remaining. (NOTE: In the case of adjustment claims, where the DME MAC
used 98 or 99 previously, the shared system shall populate the NCPDP new
version equivalent qualifying value on the COB flat file.)
3. 	Map value “05” for element 339-6C in relation to Medicare’s role as payer of
the claim.
4. 	Map the DME MAC’s workload identifier (e.g., 16003) in element 340-7C.
5. 	Map the Internal Control Number (element 993-A7) as received from CEDI and
as a result of claim adjudication.
6. 	Map the following out on the COB flat file only if received on the incoming
claim: 443-E8, 341-HB, 342-HC, 431-DV, 471-5E, 472-6E.
7. 	Create 353-NR, 351-NP, and 352-NQ in terms of primary payer’s patient
responsibility count, qualifier, and remaining amount, as applicable, or the
patient responsibility count, qualifier, and remaining amount after Medicare.
8. 	Do not map 392-MU, 393-MV, and 394-MW, as these are not used for
Medicare purposes.
9. 	Do not create any portion of the Transaction Workers’ Compensation Segment.
G. 	Transaction Claim Segment
1. 	Map 343-HD, 344-HF, and 345-HG based upon availability on the data on the
incoming claim.
2. 	Create 455-EM and 402-D2 as required, without gap-filling.
3. 	Create 403-D3, 405-D5, 406-D6, and 407-D7 as required, without gap-filling.
4. 	Create all of the following if received on the incoming claim: 408-D8, 414-DE,
415-DF, 418-DI, 419-DJ, 420-DK, 453-EJ, 445-EA, 446-EB, and 457-EP.
(NOTE: Gap-filling of 453-EJ with spaces is acceptable if the shared system is
also concurrently gap-filling 445-EA with spaces.)
5. 	Create procedure modifier count (458-SE) based upon claim adjudication.
6. 	Create procedure modifier code as appropriate.
7. 	Map 442-E7 and 426-E1 as required, without gap-filling.

8. 	Create 456-EN, 420-DK, 308-C8, and 429-DT to the COB file if received on
the incoming claim.
9. 	Map 454-EK (now required in certain situations) and 600-2B if received on the
incoming claim.
10. Do not create 461-EU, 462-EV, 463-EW, 464-EX, 354-NX, 357-NV, 995-E2,
996- G1, and 147-U7 if received on the incoming claim.
11. Always create 391-MT (“Patient Assignment Indicator”) on the COB flat file.
(NOTE: CEDI shall reject NCPDP claims with this element missing at the
DME MAC’s front-end.)
H. 	Transaction Compound Segment
1. 	Create all of the following required elements without gap-filling: 447-EC, 448-
ED, 449-EE, 450-EF, 451-EG, 488-RE, and 489-TE.
2. 	Create the following based upon claims adjudication: 412-DC, 423-DN, 426-
DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480-H9.
3. 	Create the following if received on the incoming claim: 490-UE, 362-2G, and
363-2H.
I. 	Transaction Pricing Segment
1. 	Create the following required elements without gap-filling: 409-D9 and 430-
DU.
2. 	Create the following based upon claims adjudication: 412-DC, 423-DN, 426-
DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480-H9.
3. Do not create 482-GE, 483-HE, and 484-JE.
J. 	Transaction Prior Authorization Segment - Do not create for COB flat file.
K. 	Transaction Clinical Segment
1. 	Create all situational elements indicated only if received.
2. 	Do not create “Transaction Additional Doc” segment or Additional
Documentation Type ID (369-2Q), as they relate to passage of CMN
information, which is no longer supported.
L. 	Transaction Facility Segment

Create associated elements only if received; otherwise, do not attempt to gap-fill.
M. 	Narrative Segment.
Create the 390-BM (Narrative Message) element only if information is populated on the
inbound NCPDP new version batch claim.
III. 	NCPDP New Version Gap-Filling Requirements
The DME MAC shared system shall observe the following gap-filling requirements when
creating NCPDP new version COB flat files for transmission to the BCRC:
A. For rare instances where there is not a valid base 5-byte zip code available to
populate a required zip code field, VMS shall populate “96941” within the field
corresponding to that segment on the NCPDP new version COB flat file.
B. With respect to element 322-CM (Transmission Patient Segment), when the
DME MAC’s internal beneficiary eligibility record contains blank or
incomplete line-1 street address information, VMS shall populate this element
with an initial “X” followed by 29 spaces.
C. The shared system shall continue the practice of gap-filling element 453-EJ
(Originally Prescribed Product/Service ID Qualifier) when element 445-EA
(Originally Prescribed Product Service Code) is gap-filled with spaces.
D. The shared system shall continue the practice of gap-filling 446-EB (Originally
Prescribed Quantity) when the value for this element from the inbound claim is
present but non-numeric.
E. For “skinny” processing, the shared system shall initialize elements 498-PM,
364-2J, 365-2K, 366-2M, 367-2N to spaces as a gap-fill measure.
F. 	For “skinny” processing, the shared system shall initialize element 368-2P to
zeroes as a gap-fill measure.
G. If element 427-DR (“Prescriber Last Name”) cannot be found within the DME
MAC’s internal supplier files, the shared system shall set element 427-DR to
“Unknown.”
SPECIAL NOTE: When DME MACs encounter particular gap-filling scenarios that are
not specifically addressed above, their shared system shall deploy
the current gap-fill requirements for the creation of required NCPDP
current, in use version COB flat file data content when creating
NCPDP new version COB flat files for transmission to the BCRC.

IV. 	Medigap Claim-Based Crossover Processes Involving NCPDP New Version
Claims
In advance of their acceptance of incoming NCPDP new version claims, all DME MACs
shall inform their affiliate “participating” suppliers that they may initiate Medigap claim-
based crossover processes by taking the following steps:
• 	Continue to enter the Medigap claim-based COBA ID (range 55000 to
59999) in the existing 301-C1 (Group ID) portion of the “Transmission
Insurance Segment”; and
• 	Now report the beneficiary’s Medigap policy number in the newly
developed 359-2A (Medigap ID) portion of the Transmission Claim Segment.
V. 	DME MAC NCPDP New Version Cut-Over Requirements
The BCRC shall effectuate cut-over of COBA trading partners to the NCPDP new claim
format through actions taken via the COIF.
Upon receipt of a CWF BOI reply trailer (29) that contains a “P” NCPDP new version
indicator and an “N” current, in-use (or old version) NCPDP format indicator, VMS shall
cease creation of NCPDP current, in-use (or old version) full COB claim or NCPDP
current, in use (or old version) non-SFR skinny COB claims as well as transmission of
these files to the BCRC.
VI. 	Dual BCRC Detailed Error Reports During The Transitional Period and
Accompanying New “222” Errors
During the NCPDP new version transitional period, all DME MACs shall accept and
process two BCRC Detailed Error Reports—one generated by the BCRC for claims
transmitted by the DME MACs in the current, in-use (or old) version NCPDP COB flat
file format, and another generated by the BCRC for claims transmitted by the DME
MACs in the new version NCPDP COB flat file format.
The DME MAC shared system now accept “222” error conditions as part of the BCRC
Detailed Error Report for NCPDP claims, as may be referenced in §70.6.1 of this chapter.
In this vein, the DME MAC shared system shall not effectuate changes to expand the
error description field portion of the BCRC NCPDP Detailed Error Report to
accommodate receipt of the new “222” errors.
Effective with July 2012, the BCRC will return the following new “222” errors to DME
MACs via the BCRC NCPDP Detailed Error Reports:
• 	N22230—NCPDP current, in use or old version “production” claim received,
but the COBA trading partner is not accepting that version NCPDP “production”
claims;

• 	N22231—Current, in use or old version NCPDP “test” claim received, but the
COBA trading partner is not accepting that version NCPDP “test” claims;
• 	N22232—NCPDP new version “production” claim received, but the COBA
trading partner is not accepting NCPDP new version “production” claims; and
• 	N22233—NCPDP new version “test” claims received, but the COBA trading
partner is not accepting new version NCPDP “test” claims.
IMPORTANT: The BCRC shall not begin applying “222” editing to incoming claims
until 14 calendar days after a COBA trading partner’s production cut-over to the NCPDP
new version format have elapsed. The DME MACs shall not attempt to repair claims that
the BCRC returns via the BCRC Error Reports with error codes N22230 through
N22233, regardless of error percentage.
All DME MACs shall create special provider letters to their affiliate supplier, in
accordance with §70.6.1 of this chapter, for “production” claims with error codes N22230
or N22232.
VII. 	NCPDP New Version Claims Repair Processes
The DME MACs, working with their shared system, shall initiate new version NCPDP
COB claims repair actions when: 1) the error percentage for “333” errors equals or
exceeds four (4) percent; and 2) they receive even one (1) “111” error as noted on the
BCRC Detailed Error Reports.
As part of their process to initiate a claims repair, the DME MACs shall alert their shared
system or Data Center, as per established protocol. The DME MACs shall also suppress
generation of their provider notification letters, in accordance with §70.6.1 of this
chapter, for up to 14 days.
If the DME MACs determine that the timeframes for effectuating claim repairs for “111”
or “333” errors fall outside of acceptable CMS parameters (e.g., will take 30-60 days or
longer) or if the volume of affected claims is low (1,000 claims or less per week), the
DME MACs shall allow for the release of their special provider notification letters to
affected suppliers. Any DME MACs that wish to effectuate a repair of NCPDP
“production” claims whose error percentage falls below four (4) percent shall contact a
member of the CMS COBA team before attempting that action. As a rule, CMS will
grant approval for such a repair if the volume of errored claims justifies that action and if
the time frame for repair is acceptable.
While DME MACs will not be expected to initiate the repair of “test” NCPDP claims,
they shall continue to: 1) monitor the BCRC Detailed Error Reports; and 2) notify their
shared systems of errors returned so that necessary shared system changes to improve
HIPAA compliance rates may be realized.

IMPORTANT: The DME MAC shared system shall apply NCPDP non-SFR “skinny”
logic to claim repair situations where they originally transmitted claims to the BCRC
prior to January 1, 2012, in the NCPDP prior version claim format.
80 - Electronic Transmission - General Requirements
(Rev. 4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)
The outbound COB transaction is a post-adjudicative transaction. This transaction
includes the incoming claim data as well as the COB data. A/B MACs or DME MACs
are required to receive all possible data on the incoming 837, although they do not have
to process non-Medicare data. However, the shared system must store that data in a store-
and-forward repository (SFR). This repository file is designed and maintained by the
shared system. This data must be re-associated with the Medicare claim and payment data
in order to create a compliant outbound COB transaction using the Medicare Claim/COB
flat file as input. The shared system is to use post-adjudicative Medicare data (data used
from history and reference files to adjudicate the claim) instead of data received when
building the outbound COB transaction. This is to show any changes in data element
values as a result of claims adjudication. The shared system must retain the data in the
SFR for a minimum of six months.
The Medicare Claim/COB flat file is the format to be used to re-associate all data
required to map to the COB transaction.
Data on claims that the A/B MAC or DME MAC receives from its keyshop or image
processing systems may not be included on the SFR, depending on the shared system
design. The A/B MAC and DME MAC will create the Medicare claim/COB flat file
using data available from claims history and reference files. Since some data will not be
available on these “paper” claims, the outbound COB transaction will be built as a
“minimum” dataset. It will contain all “required” COB transactions segments and post-
adjudicative Medicare data.
The steps from receipt of the incoming claim to creation of the outbound COB are
summarized below:
● 	A/B MACs and DME MACs’ translators perform syntax edits and map
incoming claim data to the ASC X12 flat file;
● 	Standard system creates any Medicare edits for the flat file data;
● 	Medicare data on ASC X12 flat file is mapped to the core system;
NOTE: There are no changes in core system data fields or field sizes.
Non-Medicare data (and Medicare data elements where field sizes are in excess of the
core system) are written to the SFR; and adjudicated data are combined with repository

data to create the outbound COB. Under the COBA process, the BCRC will receive flat
files containing processed Medicare claims. The BCRC will then convert the flat files
into the appropriate HIPAA outbound COB format and transmit the claims to the COBA
trading partner.
80.1 - Reserved
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
80.2 - Reserved
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
80.3 - Medigap Electronic Claims Transfer Agreements
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
80.3.1 - A/B MAC (A)/A/B MAC (HH) Crossover Claim Requirements
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
A. Outbound COB
The outbound COB transaction is a post-adjudicative transaction. This transaction
includes the incoming claim data as well as COB data. A/B MACs (A) are required to
receive all possible data on the incoming ASC X12 837 although they do not have to
process non-Medicare data. However, the shared system must store that data in a SFR.
This repository file will be designed and maintained by the shared system. This data
must be re-associated with Medicare claim and payment data in order to create an IG
compliant outbound COB transaction using the Medicare Part A Claim/COB flat file as
input. The shared system is to use post-adjudicated Medicare data (data used from
history and reference files to adjudicate the claim) instead of data received when building
the outbound COB transaction. The shared system must retain the data in the SFR for a
minimum of six months.
The Medicare Part A Claim/COB flat file is the format to be used to re-associate all data
required to map to the COB transaction. The translator will build the outbound COB
transaction from the Medicare Part A Claim/COB flat file.
The shared system maintainer must accommodate the COB transaction.
A/B MACs (A) shall refer to §70.6 through 70.6.5 for additional guidance concerning the
national COBA crossover process.
B. 	Summary of Process
The following summarizes all A/B MAC (A) steps from receipt of the incoming claim to
creation of the outbound COB:

A/B MAC (A)’s translator/edit process performs syntax edits, IG edits, and
Medicare edits and maps incoming claim data to the Medicare Part A Claim/COB
flat file;
Medicare data on the Medicare Part A Claim/COB flat file is mapped to the core
system by the shared system.
NOTE: No changes are being made to core system data fields or field sizes;
Non-Medicare data (and Medicare data elements where field sizes are in excess of
the core system) are written to the SFR by the A/B MAC (A)’s shared system;
and
Adjudicated data is combined with SFR data to create the outbound COB
transaction.
80.3.2 - A/B MAC (B)/DME MAC Crossover Claim Requirements
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
A. Outbound Coordination of Benefits (COB)
The outbound COB transaction is a post-adjudicative transaction. This transaction
includes incoming claim data as well as COB data. A/B MACs (B)/DME MACs are
required to receive all possible data on the incoming ASC X12 837 although they do not
have to process non-Medicare data. However, they must store that data in a store-and-
forward repository (SFR). This repository will be designed by the shared system. This
data must be re-associated with Medicare claim and payment data in order to create an
outbound ASC X12 837 COB transaction. The shared systems maintainer is to use post-
adjudicated Medicare data (data used from history and reference files to adjudicate the
claim) instead of data received when building the outbound COB transaction. A/B
MACs (B)/DME MACs must retain the data in the SFR for a minimum of six months.
The ASC X12-based flat file is the format to be used to re-associate all data required to
map to the outbound ASC X12 837. The translator will build the outbound ASC X12 837
COB from the ASC X12-based flat file.
The shared system maintainer must create the outbound ASC X12 837.
B. Summary of Process
The following summarizes all the steps from receipt of the incoming claim to creation of
the outbound COB:
● 	A/B MAC (B)/DME MAC’s translator performs syntax edits and maps
incoming claim data to the ASC X12 flat file;

● 	Standard system creates implementation guide and Medicare edits for the flat
file data;
● 	Medicare data on ASC X12 flat file is mapped to the core system;
NOTE: No changes are being made to core system data fields or field sizes.
● 	Non-Medicare data (and Medicare data elements where field sizes are in
excess of the core system) are written to the store-and-forward repository; and
● 	Adjudicated data is combined with repository data to create the outbound
COB.
90 - Reserved
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
100 - Medigap Insurers Fraud Referral
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
All MACs should give high priority to fraud complaints made by Medicare supplemental
insurers. If the referral by a Medigap insurer includes investigatory findings indicating
fraud stemming from site reviews, beneficiary interviews, provider interviews and /or
medical record reviews, all MACs should (a) conduct an immediate data run to determine
possible Medicare losses and (b) refer the case to the Office of the Inspector General
(OIG).
In addition to the referral of such cases to the OIG, all MACs should also identify and
take additional corrective action to prevent future improper payments (e.g., by placing the
provider or supplier’s claims on prepayment review). All MACs are responsible for
taking reasonable and appropriate measures to protect the Trust Fund.
110 - Medigap Criminal Penalties/Types of Complaints Under Section
1882(d)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Although most States have some type of penalty provisions regarding fraud and
misrepresentation in the sale of health insurance policies, Congress considered that many
State laws either did not directly address the following types of abuses, or else the
sanctions generally available under State laws were considered too limited. Therefore, in
order to provide an additional avenue for prosecution of these cases as well as to provide
stiff penalties (fines up to $25,000 and/or imprisonment for up to five years) these
provisions were included in Section 507 of P.L. 96-265.
A. Section 1882(d)(l) - This paragraph prohibits the making of a false representation
with regard to the compliance of a policy with the Federal requirements contained in this
law. Additionally, it prohibits the making of any false statement or misrepresentation

with respect to the use of the emblem that signifies the Secretary’s certification of a
policy under the Voluntary Certification Program. Policies submitted under this
Voluntary Certification Program were accepted for review by the Medigap Operations
Staff beginning January l, 1982. Any agent or company which represents that its policy
has received the Secretary’s certification, or that its policy has received or is eligible for
the Secretary’s emblem, when, in fact, it has not received such certification or emblem,
can be prosecuted under this paragraph. This paragraph became effective June 9, 1980.
B. Section 1882(d)(2) - This paragraph prohibits the false representation of an
association or agency relationship with the Medicare program or any Federal agency for
the purpose of selling insurance. Of the complaints received by CMS, the majority
involves alleged violations of this paragraph. These complaints indicate that agents
gained entry and, in some cases, sold policies by misrepresenting, either by direct
statement or by implication, that they were associated with Medicare, CMS, or the Social
Security Administration. This paragraph became effective June 9, 1980.
C. Section 1882(d)(3) - This paragraph provides penalties for knowingly selling
duplicative coverage (sometimes referred to as “stacking” or “loading).” This occurs
when an agent sells insurance to an individual knowing that it duplicates coverage that
he/she already has without duplicating benefits. This paragraph became effective June 9,
1980.
Although many States have statutes that specifically prohibit “twisting”
(misrepresentations made by an agent for the purpose of inducing the policyholder to
lapse, forfeit, or convert a policy), few States have specific prohibitions against
“stacking.” Therefore, Federal prosecution under §1882(d)(3) may prove to be a useful
approach where the available State statute does not specifically prohibit “stacking.”
Moreover, the Federal sanctions available for misrepresentations and “stacking” may
prove to be useful for prosecution where the available State sanctions are more limited.
D. Section 1882(d)(4) - This paragraph provides penalties for knowingly soliciting,
advertising, or offering for sale Medicare supplemental health insurance policies by mail
into a State if these policies have not been approved by the Commissioner of Insurance
for sale within the State or are not deemed to be approved for sale within the State.
Section 1882(d)(4)(B) sets out the situations for deeming that a policy is approved within
a State.
110.1 - Outline of Complaint Referral Process
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Representatives of CMS, the Office of the Inspector General (OIG) and the Department
of Justice (DOJ) have consulted to develop a coordinated procedure for the screening,
investigation, and prosecution of cases arising under these penalty provisions.
The Fraud Section, DOJ, has expressed great interest in the prosecution of these cases
and has sent an official communiqué to all U.S. Attorneys addressing the existence and

importance of the Medigap law and alerting them to the probability of referrals of cases
developed jointly by CMS, OIG, and by State Insurance Departments.
A. CMS/OIG Agreement
The CMS and OIG have reached the following agreement as to the division of functional
responsibilities with regard to the screening and investigation of alleged violations of
§1882(d):
1. 	CMS, through its regional offices, is responsible for the preliminary screening
of complaints and for providing information regarding the complaints to the
appropriate State Insurance Department.
2. 	The OIG is responsible for the investigation of cases referred by the CMS RO
and for coordinating investigatory activities with the State Insurance
Departments if requested and warranted. Further, OIG will provide any
necessary liaison between State Insurance Departments and the U.S.
Attorneys.
B. 	CMS RO Responsibilities
Upon receipt of a complaint, the RO sends an informational copy of the complaint and
any supporting documentation to the Regional Office of the Inspector General. The
Special Agents in Charge will serve as the OIG contact point for CMS referrals.
Additionally, the RO sends a copy of the original complaint and any supporting
documentation to the appropriate State Insurance Department. This is to be accompanied
by a request for information as to the status of any State investigation regarding the same
agent or company or the specific case in question.
1. 	If the State indicates that it is currently investigating, or intends to investigate the
agent or company, the RO provides any information which may be helpful to the
State and advise the State of the existence of the Federal penalty provisions and
the availability of investigatory advice and/or assistance from the Regional Office
of the Inspector General.
If the facts also indicate that a Federal violation may exist, the RO should keep
the file open and request that the State advise them as to the status and,
eventually, the disposition of the case.
If the facts indicate a possible State violation but no Federal violation, the RO out
the case after referring it to the appropriate State Insurance Department.
In either event, the RO should respond to the complainant that the case has been
referred to the State Insurance Department for investigation. The RO sends a copy

of this response to the State, Regional OIG, and to the Medigap Operations Staff
(MOS).
2. 	Where the State indicates that it does not plan to take action on the case, or where
no response is received from the State within a reasonable period of time, i.e., not
more than 30 days, the RO should proceed to screen the case. This activity
consists of:
● 	Verifying the facts alleged in the complaint; and
● 	Determining whether the facts appear to constitute prohibited activity.
3. 	Where preliminary screening indicates that a mistake of fact exists, or that the
facts do not indicate a Federal violation, the RO should respond to the
complainant and attempt to clarify the misunderstanding. The RO sends a copy of
the RO response to the complainant to MOS, the Special Agent in Charge, and the
appropriate State Insurance Department.
Verification of Facts - The A/B MAC (A, B, HH) or DME MAC logs in complaints as
they are received and establishes appropriate procedures to ensure that follow-up action is
taken on any request for additional information. Verification of facts may include
interviewing the complainant (either by phone or in person, as appropriate) to:
● 	Determine whether the facts, as originally reported, are accurate and precise;
● 	Clarify statements that are confusing or contradictory as originally recorded.
● 	Secure any missing or additional information; and
● 	Determine whether any similar complaints or additional information may be
derived from others (e.g., relatives or neighbors).
In interviewing the complainant and others, keep in mind the substantive facts that may
lead to prosecution. The MAC uses the suggested format for referral to the Regional OIG
as a checklist for the interview. As far as possible, the RO should keep the complainant
informed of the status of the action taken on the complaint. So as to maintain a high level
of cooperation; inform the complainant when he can expect to be contacted again, who
will contact him, etc.
It is important that the RO not directly contact either the agent or the insurance company
involved since this falls within the purview of investigation and is the function of the
OIG.
Referral to the Regional Office of the Inspector General - When the preliminary
screening process reveals an indication that the Federal law has been violated, refer the
case to the Regional OIG for additional development. The OIG performs the necessary

investigation and coordinates with the appropriate U.S. Attorney for prosecution. At this
point, CMS will cooperate with any request by the U.S. Attorney, State Insurance
Department, and OIG to promote timely and successful prosecution.
If there should be any questions regarding this screening and referral activity, contact the
Director, Medigap Operations Staff at the address below.
Centers for Medicare & Medicaid Services
Director, Medigap Operations Staff
7500 Security Blvd.
Baltimore, Maryland 21244-1850
110.2 - Preliminary Screening and Referral to Regional Office of the
Inspector General
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The Regional Office should perform preliminary screening activities, which may include
interviewing the complainant in person or by phone (if appropriate), in order to reach a
determination as to referral of the case for further investigation to the Special Agent in
Charge, Office of Investigations, Regional Office of the Inspector General, HHS.
At the point where the RO believes that there exists an indication of the violation of one
of the Federal penalty provisions, the RO should prepare a formal referral to the Regional
OIG. In cases where there is uncertainty as to whether the Federal law has been violated,
the case should be referred notwithstanding the uncertainty. The referral should reflect
the following information:
A. Type of violation, e.g., the complainant alleges a violation of §1882(d)(2);
B. Name, address, and telephone number of the complainant; and
C. A narrative description of the facts, which should include:
1. 	All circumstances regarding the contact made by the subject with the
beneficiary:
a. Type of contact (phone, personal);
b. Stated reason (if any) for selection of the beneficiary by the subject
making the contact, e.g.:
i. 	Beneficiary lives in a senior citizens community or
complex;
ii. The existence of another insurance policy with the same
company; and

iii. Referral by a third party.
2. 	Date, time, place, and duration of all contacts;
3. 	Words that were used to gain entry into the beneficiary’s home, e.g., “I’m
from Medicare,” “SSA,” or other Federal Government agency;
4. 	Details of the subject’s sales pitch or presentation:
a. Was there a discussion of the existence of other health insurance
policies currently held by the beneficiary?
b. Did the agent know that his policy was duplicative of Medicare or a
currently held policy?
c. Amount of premium of policy that agent was trying to sell. Obtain a
copy of the policy if possible;
d. Existence of any hard sell or intimidation tactics on the part of the
agent.
5. Details of the Agent’s exit:
a. Business card left by agent; and
b. Follow-up calls by agent or others.
D. Other Information:
1. Name of contact person in the Regional Office;
2. Copy of the original complaint; and
3. Any other supporting documentation.
110.3 - CMS Regional Office Quarterly Report on Medicare
Supplemental Health Insurance Penalty Provision Activity
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The RO’s should submit to the Director, Medigap Operations Staff, a report summarizing
activities with regard to the screening and referral of complaints falling under the penalty
provisions of §1882(d). This report will be used to compile the Secretary’s report to
Congress as required by §1882(f)(2). Under the terms of this paragraph, the Secretary
must submit a report to Congress beginning July 1, 1982 (and at least every two years

thereafter) evaluating, among other things, the effectiveness of the criminal penalties.
The following information from the Regional Offices is necessary for that evaluation.
110.3.1 - Statistics
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The number of complaints received broken down by the type of alleged violation, e.g.,
§1882(d)(2).
The origin of the complaints:
• 	Complaint was made directly to RO;
• 	Complaint was referred by other Federal agency; State agency;
• 	Complaint was referred by consumer group;
• 	Other;
• 	The number of interviews (contacts) held to validate the facts of the case;
• 	The number referred (after screening) to the Regional Office of the Inspector
General for investigation; and
• 	The number of cases closed-out:
o 	For mistake or misunderstanding;
o 	Referral to State for violations of State law;
o 	Other.
• 	The number of cases prosecuted and, for each, the name of the agent/company
and disposition of the case; and
• 	The number of cases currently pending.
110.3.2 - Narrative
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The RO provides information as to the overall success of the complaint validation and
referral procedure including the extent of cooperation among CMS, OIG, State Insurance
Departments, and the U.S. Attorneys. This information will be used to correct or
strengthen existing procedures.
This report should be submitted by the 15th of the month following the report quarter.

Transmittals Issued for this Chapter
Rev # 	Issue Date Subject 	Impl Date 	CR#
R13314CP 07/24/205 	Modifications to the National Coordination
of Benefits Agreement (COBA) Medicare
Claims Crossover Process
01/05/2026 14139
R11939CP 04/05/2023 Process Improvements for the National
Coordination of Benefits Agreement
(COBA) Detailed Error Reporting
Notification Process
07/06/2023 13154
R10638CP 03/09/2021 Modernization of the Electronic Files
Transfer (EFT) Associated with the National
Coordination of Benefits Agreement
(COBA) Crossover Process
04/05/2021 12053
R10559CP 01/20/2021 Modernization of the Electronic Files
Transfer (EFT) Associated with the National
Coordination of Benefits Agreement
(COBA) Crossover Process- Rescinded and
replaced by Transmittal 10638
04/05/2021 12053
R4281CP 	04/19/2019 Update to Chapter 28 in Publication (Pub.)
100-04 to Provide Language-Only Changes
for the New Medicare Card Project
05/20/2019 11261
R4243CP 	02/15/2019 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
04/01/2019 10961
R4160CP 	11/02/2018 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process- Rescinded and replaced by
Transmittal 4243
04/01/2019 10961
R4157CP 	11/02/2018 Hospital and Critical Access Hospital
(CAH) Swing-Bed Manual Revisions and
Shared Systems Changes
04/01/2019 10961
R4069CP 	06/08/2018 Alignment of Coordination of Benefits
Agreement (COBA) Internet Only Manual
References
07/09/2018 10737

Rev # 	Issue Date Subject 	Impl Date 	CR#
R3714CP 	02/03/2017 Changes to the National Coordination of
Benefits Agreement (COBA) Crossover
Process as a Result of the Social Security
Number Removal Initiative (SSNRI)
07/03/2017 9885
R3004CP 	08/01/2014 Modification to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
01/05/2015 8731
R2906CP 	03/14/2014 Pub 100-04, Chapter 28 language-only
update for ASC X12 version 5010,
implementation of MACs, and MAC
coordination with Medigap, Medicaid and
Other Complementary Insurers
04/14/2014 8540
R2904CP 	03/14/2014 Pub 100-04, Chapter 28 language-only
update for ASC X12 version 5010,
implementation of MACs, and MAC
coordination with Medigap, Medicaid and
Other Complementary Insurers
04/14/2014 8540
R2810CP 	11/07/2013 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
04/07/2014 8454
R2569CP 	10/26/2012 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
04/01/2013 8071
R2215CP 	05/13/2011 Modifications to the COBA Process for
Other Federal Payer Payment Order and
Other Issues
10/03/2011 7393
R2189CP 	04/04/2011 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process Stemming Principally From the
Affordable Care Act (ACA)
04/04/2011 7136
R2181CP 	03/25/2011 Medicare Claims Processing Pub. 100-04
Chapter 24 Update for HIPAA 5010 and
EDI Enhancements
04/25/2011 7269

Rev # 	Issue Date Subject 	Impl Date 	CR#
R2090CP 	11/10/2010 Implementation of Errata for Version 5010
of Health Insurance Portability and
Accountability Act (HIPAA) Transactions,
and Updates in 837I, 837P, and 835 Flat
Files
04/04/2011 7202
R2087CP 	11/05/2010 Implementation of Errata for Version 5010
of Health Insurance Portability and
Accountability Act (HIPAA) Transactions,
and Updates in 837I, 837P, and 835 Flat
Files – Rescinded and replaced by
Transmittal 2090
04/04/2011 7202
R2076CP 	10/28/2010 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process Stemming Principally From the
Affordable Care Act (ACA) – Rescinded
and replaced by Transmittal 2189
04/04/2011 7136
R1920CP 	02/19/2010 Modifications to Gap-Filling Requirements
for the Health Insurance Portability
Accountability Act (HIPAA) 837 version
5010 Coordination of Benefits (COB)
Claims Transactions and National Council
for Prescription Drug Programs (NCPDP)
Version D.0 Claim Files
07/06/2010 6816
R1844CP 	11/06/2009 Additional Health Insurance Portability and
Accountability Act (HIPAA) 837 5010
Transitional Changes and Further
Modifications to the Coordination of
Benefits Agreement (COBA) National
Crossover Process
04/05/2010 6658
R1841CP 	10/29/2009 National Council for Prescription Drug
Programs (NCPDP) Version D.0.
Coordination of Benefits (COB)
Requirements for the National Claims
Crossover Process
04/05/2010 6664
R1727CP 	05/01/2009 Coordination of Benefits Agreement
(COBA) Repair and Claims Recovery
10/05/2009 6420

Rev # 	Issue Date Subject 	Impl Date 	CR#
Requirements Stemming from the Health
Insurance Portability and Accountability Act
(HIPAA) 5010 Claims Transactions
R1720CP 	04/24/2009 Health Insurance Portability and
Accountability Act (HIPAA) American
National Standards Institute (ANSI) 837
5010 Coordination of Benefits (COB)
Requirements--Part II
07/06/2009 6374
R1704CP 	03/20/2009 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
07/06/2009
and
10/05/2009
6343
R1640CP 	11/21/2008 Modifications to the National Coordination
of Benefits Agreement (COBA) Process
04/06/2009 6234
R1568CP 	08/01/2008 Health Insurance Portability and
Accountability Act (HIPAA) American
National Standards Institute (ANSI) X12-N
837 version 5010 Changes Necessary for
Coordination of Benefits (COB) and other
Coordination of Benefits Agreement
(COBA) Process Revisions
01/05/2009 6103
R1507CP 	05/16/2008 Coordination of Benefits Agreement
(COBA) and Affiliate National Provider
Identifier (NPI) Process Modifications
10/06/2008 6024
R1497CP 	05/02/2008 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
07/07/2008 6037
R1436CP 	02/05/2008 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process – Replaced by Transmittal 1497
07/07/2008 5866
R1420CP 	01/25/2008 Clarification Regarding the Coordination of
Benefits Agreement (COBA) Medigap
Claim-Based Crossover Process
02/01/2008 5837

Rev # 	Issue Date Subject 	Impl Date 	CR#
R1332CP 	08/31/2007 Transitioning the Mandatory Medigap
(“Claim Based”) Crossover Process to the
Coordination of Benefits Contractor
(COBC)
10/01/2007 5601
R1296CP 	07/18/2007 Modifications to the National Coordination
of Benefits Agreement (COBA) Crossover
Process
10/01/2007 5569
R1282CP 	07/06/2007 Medicare Contractors Use of the
Coordination of Benefits Agreement
(COBA) Problem Inquiry Request Form and
Send COBA Related Issues to the COB
Contractor
08/06/2007 5656
R1242CP 	05/18/2007 Transitioning the Mandatory Medigap
(“Claim Based”) Crossover Process to the
Coordination of Benefits Contractor
(COBC)
10/01/2007 5601
R1232CP 	04/27/2007 Modification to the Coordination of Benefits
Agreement (COBA) Crossover Process -
Replaced by Transmittal 1296
10/01/2007 5569
R1189CP 	02/28/2007 Differentiating Mass Adjustments From
Other Types of Adjustments and Claims for
Crossover Purposes and Revising the
Detailed Error Report Special Provider
Notification Letters – Replaced by
Transmittal 1189
07/02/2007 5472
R1179CP 	02/02/2007 Differentiating Mass Adjustments From
Other Types of Adjustments and Claims for
Crossover Purposes and Revising the
Detailed Error Report Special Provider
Notification Letters – Replaced by
Transmittal 1189
07/02/2007 5472
R1110CP 	11/09/2006 Excluding Sanctioned Provider Claims from
the Coordination of Benefits Agreements
(COBA) Crossover Process
04/02/2007 5353

Rev # 	Issue Date Subject 	Impl Date 	CR#
R1038CP 	08/25/2006 COBC Sending Copy of Trading Partner's
Eligibility File to Medicare Contractor for
Use in Recovery Process
01/02/2007 5250
R1006CP 	07/21/2006 Modification to the Coordination of Benefits
Agreement (COBA) Claims Selection
Criteria and File Transfer Protocols
10/02/2006 5094
R967CP 	05/26/2006 Modification to the Coordination of Benefits
Agreement (COBA) Claims Selection
Criteria and File Transfer Protocols
10/02/2006 5094
R837CP 	02/03/2006 Coordination of Benefits Agreement
(COBA) Full Claim File Repair Process
07/03/2006 4277
R666CP 	09/02/2005 Updates to the Coordination of Benefits
Contractor (COBC) Detailed Error Report
File Layouts
10/03/2005 4042
R586CP 	06/17/2005 Modification to the National Coordination
of Benefits Agreement (COBA) File
Transfer and Financial Reporting Processes
10/03/2005 3906
R474CP 	02/11/2005 Detailed Error Report Notification Process
to COBA Partners
07/05/2005 3709
R448CP 	01/21/2005 Timeframe for Execution of Crossover
Agreements and Update on the Transition to
the National Coordination of Benefits
Agreement (COBA) Program
02/22/2005 3658
R250CP 	07/23/2004 Update of CWF Procedures 	01/03/2005 3404
R158CP 	04/30/2004 Transition to Medicare Coordination of
Benefits Contractor (COBC)
10/04/2004 3273
R138CP 	04/09/2004 Transition to Medicare Coordination of
Benefits Contractor (COBC)
07/06/2004 3218
R098CP 	02/06/2004 Transition to Medicare Coordination of
Benefits Contractor (COBC)
07/06/2004 3109

Rev # 	Issue Date Subject 	Impl Date 	CR#
R001CP 	10/01/2003 Initial Publication of Manual 	NA 	NA
Back to top of Chapter