100-04 Medicare Claims Processing Manual: Chapter 27 - Contractor Instructions for CWF

Medicare Claims Processing Manual
Chapter 27 - Contractor Instructions for CWF
Table of Contents
(Rev. 13314, 07-24-25)
Transmittals for Chapter 27
10 - General Information About the Common Working File (CWF) System
20 - Common Working File (CWF) Operations
20.1 - Communication between Host and MAC’s Jurisdiction Sector
20.2 - Records received by the CWF Hosts
20.2.1 – Beneficiary Data Streamlining (BDS)
20.2.2 - Claims
20.2.3 – Adjustments/Cancels to Posted Claims
20.2.4 - Claim Maintenance Records
20.3 - Records received from the CWF Hosts
20.3.1- BDS Basic Reply
20.3.2- Claims Basic Reply
20.3.2.1 - Accepted (as is) for Payment
20.3.2.2 - Adjusted and Then Accepted for Payment
20.3.2.3 - Cancel/Void Claim Accepted
20.3.2.4 - Rejected
20.3.3 - Not in Host's File (NIF)
20.3.3.1 - Disposition Code 50 (Not in File)
20.3.3.2 - Disposition Code 51 (True Not in File on CMS Batch
System)
20.3.3.3 - Disposition Code 52 (Beneficiary Record at Another
Host)
20.3.3.4 - Disposition Code 53 (Record in CMS Alpha Match)
20.3.3.5 - Disposition Code 54 (Matched to Cross-referenced
HICN)
20.3.3.6 - Disposition Code 55 (Personal Characteristic Mismatch)
20.3.3.7 - Disposition Code 56 (MBI/HICN Mismatch)
20.3.4 - Claim Maintenance Records Basic Reply

20.3.5 - Unsolicited Response/Informational Unsolicited Response
(UR/IUR)
30 - Reviewing the Beneficiary and Claim(s) Information
30.1- Online Health Insurance Master Record (HIMR) Display
30.2- CWF Provider Queries - Online Eligibility Information for Medicare Part A
Providers
30.3- Online Reporting (ORPT) System Display
40 - Requesting Assistance in Resolving CWF Utilization
40.1- Requesting Assistance in Resolving CWF Utilization Problems
40.2- Social Security Administration (SSA) Involvement
40.3 - Critical Case Procedure - Establishing Entitlement
40.4 - Referral of Critical Cases to the Regional Office
50 - Requesting or Providing Assistance to Resolve CWF Rejects
50.1 - Requesting A/B MAC or DME MAC Action
50.2 - Assisting A/B MAC or DME MAC Action
50.3 - Format for Requesting Assistance From Another A/B MAC or DME MAC
on CWF Edits
Exhibit 1 - Request for Assistance
60 - Paying Claims Outside of CWF
60.1 - Requesting to Pay Claims Outside of CWF
60.2- Procedures for Paying Claims Outside of CWF
60.3 - Contractor Monthly Reports of Claims Paid Outside of CWF
70 - Change Control Procedures
70.1- MAC Procedure
70.2 - Process Flow of a Change Request
70.3 - Handling Emergency Problems and Problems With Recent CWF Releases
70.4 - Distribution of "CWF Change Control" Reports
70.5 - Channels of Communication
70.6 - Schedule of CWF Software Releases
80 - Processing Disposition and Error Codes
80.1 - Disposition Codes
80.2 - Error Codes

80.3 - Beneficiary Other Insurance Information (HUBO) Maintenance
Transaction Error Codes
80.4 - Consolidated Claims Crossover Process
80.5 - Claims Crossover Disposition and Coordination of Benefits Agreement
Bypass Indicators
80.6 - Special Mass Adjustment and Other Adjustment Crossover Requirements
80.7 - Coordination of Benefits Agreement (COBA) Medigap Claim-Based
Crossover Process
80.8 - Inclusion and Exclusion of Specified Categories of Adjustment Claims for
Coordination of Benefits Agreement (COBA) Crossover Purposes
80.9 - Health Insurance Portability and Accountability Act (HIPAA) 5010 and
National Council for Prescription Drug Programs (NCPDP) D.0 Crossover
Requirements
80.10 - Inclusion and Exclusion of Specified Part B Claims for Coordination of
Benefits Agreement (COBA) Crossover Purposes

10 - General Information About the Common Working File (CWF)
System
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The Common Working File (CWF) is the Medicare Part A and Part B beneficiary
benefits coordination and pre-payment claims validation system which uses localized
databases maintained by designated contractors called ‘CWF Hosts’. The CWF System
software is duplicated and utilized by the nine CWF Hosts localized databases to process
claims.
Each Medicare beneficiary is assigned to only one Host site based on beneficiary
geographic location. CWF Hosts maintain total beneficiary claim history and entitlement
information for the beneficiaries in their jurisdiction.
Each jurisdiction is a network of A/B Medicare Administrative Contractors
(MACs) and Durable Medical Equipment Medicare Administrative Contractors
(DME MACs), termed “Satellites,” and located in a defined geographic area
(sector). Each MAC within the sector is linked to its Host via
telecommunications through their respective CMS Virtual Data Center (VDC).
The Medicare Part A, B or DME processing system creates a nightly CWF file out of the
MACs processing region, containing claims data. The corresponding MAC’s VDC
transmits these files to the CWF Host. The CWF Host uses the CWF software and
determines the beneficiary's eligibility and entitlement status and uses that information to
decide what action should be taken on the claim. The CWF software also checks
incoming claims against all other claims types, referred to as A/B crossover, previously
processed and stored in claims history to prevent duplicate payments. The Host returns a
response file back to the VDC and the file is loaded to the MACs processing region. The
file will contain various disposition codes, trailers, and error codes, used by the
processing systems in automatic processing during the batch cycle. The responses are
applied to the pending claim allowing appropriate system action.
20 - Common Working File (CWF) Operations
(Rev. 11427; Issued: 05-20-22; Effective: 01-01-23; Implementation: 01-03-23)
NOTE: CMS seeks to reduce burden and modernize processes to ensure a reduction in
improper payments and an increase in customer satisfaction. The Certificate of Medical
Necessity (CMN) form and DME Information Form (DIF) were originally required to
help document the medical necessity and other coverage criteria for selected Durable
Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) items. In the past, a
supplier received a signed CMN from the treating physician or created and signed a DIF
to submit with the claim. Due to improvements in claims processing and medical records
management, the information found on CMNs or DIFs is available either on the claim or
in the medical record and is redundant. Therefore, to reduce burden and increase

customer satisfaction, providers and suppliers no longer need to submit these forms for
services rendered after January 1, 2023.
• 	For claims with dates of service on or after January 1, 2023 – providers and
suppliers no longer need to submit CMNs or DIFs with claims. Due to electronic
filing requirements, claims received with these forms attached will be rejected and
returned to the provider or supplier.
• 	For claims with dates of service prior to January 1, 2023 – processes will not
change and if the CMN or DIF is required, it will still need to be submitted with
the claim, or be on file with a previous claim.
This statement applies throughout the Program Integrity Manual wherever CMNs and
DIFs are mentioned.
This section is intended only to be a brief profile synopsis of CWF operations. The
system and user documentation should be closely examined for further details.
The Common Working File system provides a single data source where the contractors
can verify beneficiary eligibility to receive prepayment review and approval of claims.
Each Host site is responsible for processing those claims submitted for beneficiaries on
its database. These claims are processed through a shared software system supplied to
each Host by the CWF Maintenance Contractor (CWFM). Each change made to the CWF
software is released to all Host sites in a uniform manner. This software performs
consistency and utilization editing on claims for corrective action by the MAC’s.
The CWF system ensures that:
1. 	The beneficiary is entitled to either Part A or Part B benefits, depending on
the type of claim submitted.
2. 	The co-pay and/or deductible applied, if any, is accurate.
3. 	Services are allowed.
4. 	Benefits are available for the services submitted on the claim
The CWF system also ensures that the services on the claim have not been paid on
another claim - either the same type or another type of claim. If any of these conditions
occur, the CWF system returns a response and identifies the reason for the rejection. The
response also includes one or more trailers that identify the correct information necessary
for the Medicare contractor to take the necessary action.
Prior to adjudication of claims, the CWF Host will send the claim to Fraud Prevention
System (FPS) for review. FPS will make a payment determination which will be sent to
the CWF Host. The CWF Host will then process the claims through consistency and
utilization to ensure beneficiary is entitled to either Part A or Part B benefits, depending
on the type of claim submitted.
Once the claim passes all of the edits, the CWF beneficiary master file is updated to
reflect the benefits now available, as well as any changes to the deductible status. The
claim is added to the CWF full claim history file.

CWF also provides eligibility and entitlement check via the beneficiary data streamlining
(BDS) system which occurs earlier in the claims lifecycle to check for Medicare
beneficiary identifier, eligibility and entitlement prior to the submission of the claim.
20.1 - Communication between Host and MAC’s Jurisdiction Sector
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The local CWF database for each sector resides at a Host. Each A/B and DME MAC
within the sector is linked to its Host's database. Communication between them is
electronic, with claims ready for payment or denial communicated to the Host, and
adjustments, approvals, rejects, and informational trailers returned from the Host via a
daily process. The A/B and DME MAC’s usually initiates this process. On occasion, the
CWF Host will initiate an "unsolicited response" to the A/B and DME MAC’s as a result
of a new claims action that affects a previously processed claim action.
Claims are processed by CWF in the same order that they are received, regardless of the
dates of service or receipt date. This first-in-first-out method of processing requests for
payment facilitates prompt handling of claims.
Role of CWF Hosts:
• 	Responsible for executing a common set of CWF software modules to maintain
Beneficiary databases by adding or updating Beneficiary entitlement information
provided by CMS
o 	These updates are processed by the enrollment database (EDB) and
continue to update CWF Host records as the beneficiary's entitlement
changes.
• 	Perform consistency; utilization, A/B cross over and duplicate edit checks to
provide authorization for MAC’s to pay claims;
• 	Providing and controlling linkage of the MAC’s in the sector to the Host;
Controlling and monitoring telecommunications network operations
• 	Supplying MAC’s with inquiry and transmission software necessary to
communicate with the Host and make full use of the CWF data inquiry features;
• 	Receiving, installing, testing, and operating the CWF software system, including
all changes developed by CWFM;
Role of A/B and DME Medicare Administrative Contractors (MACs):
• 	Submission of claims via telecommunication in batch mode to a CWF Host for
validation and payment approval;
• 	Receive, control, and enter claims into an automated processing system.
• 	Review, edit, and adjudicate claims through CWF system for determination of
eligibility, coverage, and pricing.
• 	Submission of online inquiries to a CWF Host to determine Beneficiary
enrollment status and eligibility
• 	Submit claims to the CWF Host for pre-payment validation and authorization.

• 	Issue payments to Providers or deny/develop claim is rejected by CWF; - Issue
Explanation of Medicare Benefits and payments to Beneficiaries.
20.2 - Records received by the CWF Hosts
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
20.2.1 - Beneficiary Data Streamlining (BDS)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The BDS system provides access to a common eligibility service which occurs earlier in
the claims lifecycle than the CWF eligibility check. The BDS transactions, 'HBDA' for
Part A, 'HBDB' for Part B, and 'HBDD' for DME, will allow the Shared Systems claims
processing to query eligibility edits for Part A, Part B, and DME claims. The BDS system
uses the CWF data repository to provide eligibility and entitlement responses to the
Shared Systems query. The information is returned on a BDS Basic Reply Record. (See
§20.3.1) BDS records can be of the following types:
• 	A/B MAC (A) Claim Record: 	A/B MAC (A) bills are input on the HBDA
record.
• 	A/B MAC (B) Claim Record: A/B MAC (B) bills are input on the HBDB record.
• 	DMEPOS Claim Record: DMEPOS bills are input on the HBDD record.
20.2.2 – Claims
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The CWF Claim Record is a record of a claim that the MAC has processed and is ready for
payment or denial. 	It is submitted in daily files to the Host for approval. 	Prior to the
approval CWF Host will send the claim to Fraud Prevention System (FPS) for review.
Role of FPS:
FPS interacts directly with the CWF Hosts and performs these functions:
• 	Receive files submitted by CWF Hosts with claims approved for payment.
• 	Process claims using proven predictive modeling tools to identify high risk claims.
• 	Make a payment determination that is returned to the CWF Hosts for appropriate
action. Only denied claims will be included in the returned file.
The Host clears the claim record through regular CWF consistency edits, utilization edits
and A/B crossover edits, in that order, and makes its approval, adjustment or rejection
determination. The final determination is returned on a Claim Basic Reply Record. (See
§20.3.2) Claim records can be of the following types:
• 	Part B Claim Record: Part B bills are input on the HUBC record.
• 	DMEPOS Claim Record: DMEPOS bills are input on the HUDC record.

• 	Inpatient/Skilled Nursing Facility Claim Record: Inpatient hospital and SNF
bills are input on the HUIP record.
• 	Outpatient Claim Record: Outpatient bills are input on the HUOP record.
• 	Home Health Claim Record: Home health bills are input on the HUHH record
• 	Hospice Claim Record: Hospice bills are input on the HUHC record.
20.2.3 - Adjustments/Cancels to Posted Claims
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Two actions can be taken on a claim that is already posted to CWF history. These actions
are the same whether submitted by an A/B MAC or DME MAC; however, the codes used
are different:
• 	Void - Use a void to cancel original data on the beneficiary database and totally
remove the dollar amounts. To void a posted claim, send the claim with the
original document control number and a "Full Credit" code (Entry Code 3 for A/B
MACs (B) and DME MACs and Action Code 4 for A/B MACs (A, HHH))).
• 	Change - Send a full claim with a "Replacement Debit" code (Entry Code 5 for
A/B MACs (B) and DME MACs and Action Code 3 for A/B MACs (A, HHH)) and
the original document control number to make a change to a posted claim. This
code is used to change most claims information. The old claim information will
be backed out and replaced with the new claim information. The CWF will keep
a record of the old claim so that any investigation of the actions taken on the
claim will include the fact that there was a replacement action taken.
20.2.4 - Claim Maintenance Records
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The CWF Claim Maintenance Record is a record of a transaction that the Medicare
Administrative Contractors are submitted in daily files to the CWF Host to update the
related auxiliary file information that is used for claims processing approval. The final
determination is returned on a Basic Reply Record. (See §20.2.2.) Claim Maintenance
records can be of the following types:
• 	Medicare Secondary Payer (MSP): Medicare Secondary Payer information
(Primary insurer data when Medicare is secondary) is input on the HUSP record.
• 	End Stage Renal Disease (ESRD): Beneficiary ESRD data input on the HURD
record.
• 	Certified Medical Necessity (CMN): Beneficiary Certified medical necessity
data is input on the HUCM record.
• 	Beneficiary Other Insurance Information (BOI): Beneficiary Other insurance
information data is input on the HUBO record.

• 	Beneficiary Libby Montana (Libby): Beneficiary Libby information data is
input on the HUEP record.
• 	Beneficiary Prior Authorization (PRAU): Prior Authorization data is input on
the HUPA record.
• 	Intravenous Immune Global (IVIG): Beneficiary Intravenous Immune Globulin
information data is input on the HUIV record.
20.3 - Records received from the CWF Hosts
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
20.3.1 – BDS Basic Reply
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When the Host receives a query from MAC’s requesting beneficiary eligibility and
entitlement information, the informational record is sent in response to the BDS
Transaction record sent to the host. It acknowledges the Host's receipt of the BDS
Transaction record and indicates any errors or informational data.
Following are the types of codes and other information associated with this record: These
codes are returned on Basic Reply Trailer 08 and other reply trailers as appropriate
• 	Disposition codes;
• 	Error codes; and
• 	Basic Reply Trailers.
20.3.2 - Claims Basic Reply
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When the Host receives each claim or adjustment, it searches the Beneficiary File to find
the Beneficiary Record. If the Beneficiary Record is found, the record is processed and a
reply record is transmitted to the MAC. See §20.3.3, for an explanation of the procedure
if the Beneficiary Record is not found ("Not in File.") The record type returned by CWF
is dictated by the claim record type as follows:
• 	A/B MAC (B) Basic Reply Record - Reply record for each CWF A/B MAC (B)
bill (HUBC) processed.
• 	DMEPOS Basic Reply Record - Reply record for each CWF DMEPOS bill
(HUDC) processed.
• 	Inpatient/SNF Bill Basic Reply Record - Reply record for each Inpatient/SNF
bill (HUIP) processed.
• 	Outpatient/Home Health Bill Basic Reply Record - Reply record for each
Outpatient/Home Health bill (HUOP and HUHH) processed

• 	NOE/Hospice Bill Basic Reply Record - Reply record for each Hospice Notice
of Election and all subsequent Hospice bills (HUHC) processed.
Each reply record will contain a disposition code and error code that indicates the action
taken on the bill by the Host and what action the MAC should take next.
The following is a list of actions that CWF may take on a claim record. Disposition
codes, cross-reference/alpha search/NIF situations, their associated trailers, and bill
recycling instructions are also included:
20.3.2.1 - Accepted (as is) for Payment
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The claim record is posted to CWF history as submitted to the Host. The MAC pays the
claim accordingly.
• 	Disposition code 01.
• 	Basic Reply Trailers - These are informational trailers that contain entitlement,
utilization, MSP, or other information, as appropriate, and are returned with the
Reply. They give the MAC the most recent information available about the
beneficiary's claim history and other important data. MACs must use this
information to update their own data to improve the accuracy of future claims
processing.
• 	Return Alerts - These are sent to the MAC when CWF believes that there is a
potential problem or error in the claim. The presence of an alert indicates that the
MAC should examine the information and make adjustments if necessary.
20.3.2.2 - Adjusted and Then Accepted for Payment
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The deductible and/or payment limitations field(s) on the claim record were in error and
CWF recalculated the field(s). The Host posts the record to CWF after these corrections
are made. The MAC must make the same adjustments to its files using information from
basic reply Trailers 07 and 11 and pay the claim accordingly. MACs must not resubmit
the claim to CWF.
• 	Disposition code 02
• 	Basic Reply Trailers (07 and 11)
• 	A/B Crossover Alerts
20.3.2.3 - Cancel/Void Claim Accepted
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
This action cancels or voids a previously processed claim posted to CWF History. All
utilization and deductibles associated with the claim are backed out. The MAC receives
a disposition code informing it that the cancel/void action was accepted.

• 	Disposition code 03
• 	Basic Reply Trailers
20.3.2.4 - Rejected
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The claim record contains errors that prevent CWF from posting the claim to history.
The claim is returned to the MAC with codes explaining the errors. The MAC must
correct the CWF Claim Record and resubmit it.
• 	Disposition Code ER, UR, CR, or AA, as Appropriate - There will never be a
combination of ER, UR, CR, and AA error codes on the same reply.
• 	Consistency Error Codes (ER) - Consistency edits examine the information on
the claim itself. The consistency error codes indicate the errors in consistency
found on the claim. These codes are returned on Basic Reply Trailer 08 and can
contain up to four consistency error codes.
• 	Utilization Error Codes (UR) - Utilization edits compare the information on the
CWF Claim Record with the information found on the CWF Beneficiary Master
Record. The utilization error codes indicate discrepancies between the CWF
Claim Record and the CWF Beneficiary Master Record. Since the CWF
Beneficiary Master Record is presumed to be correct, these codes inform the
MAC what corrections it must make. The code is returned on basic reply Trailer
08 and contains only one utilization error code.
FPS: If FPS denies the claim record, CWF will stop processing the claim and
return a response back to the MAC with FPS error code.
• 	Disposition Code UR – The utilization error code indicate the errors found on
the claim. These codes are returned on Basic Reply Trailer 08, 48 and 49
indicating partial denial (FPSD) or full denial of the claim (FPSH).
• 	A/B Crossover Edits (CR) - When the Host receives a Part A bill, CWF
automatically checks the information in the record against the beneficiary's
history files for both Part A and Part B utilization. If there is a conflict (or
"crossover") of services, CWF will generate an A/B Crossover error code. These
are returned on the reply Trailer 13 and will contain only one A/B crossover error
code.
20.3.3 - Not in Host's File (NIF)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When the Host receives a claim record from a MAC, it first searches its beneficiary and
cross reference files. If it does not find the beneficiary's record in either place, it searches
the Transfer Not in File (TNIF) file. If the record is not found there, the Host puts a
response on the reply record in the form of a disposition code 50 or 52, indicating that the

Beneficiary Record for which the MAC submitted a claim record is not located at the
MAC's Host.
The TNIF file contains a record of every beneficiary for whom the Host has received a
claim, and whose records are located at another Host. It shows at which Host the
beneficiary file resides. If the Beneficiary Record is located at another Host, the original
Host checks the out-of-service area response file to see if the claim record response is
already waiting there. If there is not a response waiting, the claim is sent to the proper
Host for processing. If there is a response, the Host gives that information to the MAC.
There are many disposition codes that are returned to the MAC for various NIF
situations. Following is a list of codes and actions the MAC takes in response to each
disposition code.
20.3.3.1 - Disposition Code 50 (Not in File)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Disposition code 50 can come with any of the following seven error codes:
1. With Error Code 5052 - Beneficiary Identification Incorrect - The name and/or claim
number shown on the bill is incorrect or claim number is not in file. If the TNIF file does
not indicate another Host, the beneficiary's records may not have been assigned to a Host
and are still resident at CMS or the beneficiary was assigned to another Host site and the
TNIF File was not updated. When the Host is not sure which is the case, it gives
disposition code 50 and Trailer 08 with error code 5052 on the reply to the MAC. A/B
MACs and DME MACs verify through inquiry to the Host that the HICN is correct on the
bill. If the bill is correct, and the Host HIMR agrees with the reject (no record), A/B
MACs and DME MACs must notify the Host of the error. The Host will contact CMS to
determine eligibility.
2. With Error Code 5054 - The Host returns code 50 with Trailer 08 and error code
5054 when an auxiliary indicator is present on the CWF Beneficiary Master Record, but
no auxiliary record is found.
• 	Concurrent with this response to the MAC, the Host sends a request for transfer to
CMS requesting the beneficiary's records from CMS' Master File.
• 	The A/B MAC or DME MAC must recycle the claim every four working days until
an approval, adjustment or reject (AAR) response is received, or 45 working days
have passed since receipt of the original code 50.
• 	The A/B MAC or DME MAC reports through locally established procedures to the
Host if 45 days pass with no AR response.
3. With Error Code 5055 - The Host returns code 50 with Trailer 08 and error code
5055 (Beneficiary Blocked at CWF Host and CMS Batch Pending Clerical Update) if

CMS must investigate a beneficiary's entitlement because of suspicion of fraud or abuse.
The MAC recycles the claim every 15 working days until otherwise notified.
Definition of Day One for CWF MAC Recycle - Day one is the day that the
MAC receives the disposition code back from the Host. For example, a MAC
sends the update file to the Host on Monday, April 1, at 10 p.m. The MAC
receives the response file from its Host site at 9 a.m. Tuesday, April 2. Tuesday,
April 2, is day one for MAC recycle.
4. With Error Code 5056 - The Host returns code 50 with Trailer 08 and error code
5056 (Skeleton - No Beneficiary Record on HI Master File) when the HICN involved is
for a beneficiary whose date of death is prior to 1975.
• 	The records for these beneficiaries have been purged from the file.
• 	A/B MACs and DME MACs research the HICN and confirm that the HICN
submitted on the claim is correct. If incorrect, it resubmits the claim with the
correct HICN.
• 	If the originally submitted HICN was correct, A/B MACs and DME MACs refer
the case to the RO.
5. With Error Code 5057 - The Host returns disposition code 50 with Trailer 08 and
error code 5057 (Skeleton on HI Master File). This indicates that the beneficiary has
died.
• 	There has been no claims activity for six months since date of death, and the
beneficiary information is located on the inactive file.
• 	A/B MACs and DME MACs research the HICN and confirm that the HICN
submitted on the claim is correct. If incorrect, resubmit the claim with the correct
HICN.
• 	If the originally submitted HICN was correct, the A/B MAC or DME MAC
recycles the claim every 15 working days to allow CMS time to retrieve the
records.
• 	After 45 working days have passed with no approval, adjustment, or reject (AAR)
response, MACs contact their RO.
6. With Error Code 5058 - The Host returns disposition code 50 with Trailer 08 and
error code 5058 (Blocked). The records have been blocked due to cross-reference
activity. There are two numbers for one beneficiary, both of which show claims activity.
The information is manually placed under one primary number in one record.

• 	MACs recycle the claim every 15 working days to allow time for CMS
processing.
• 	After receiving a second code 58, they contact the RO.
7. With Error Code 5059 - The Host returns this as disposition code 50 and Trailer 08
with error code 5059 (Frozen). Miscellaneous clerical corrections are being made to
these beneficiary records.
• 	MACs recycle the claim every 15 working days.
• 	After receiving a second code 59, the A/B MACs or DME MACs contact the RO.
20.3.3.2 - Disposition Code 51 (True Not in File on CMS BatchSystem)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The Host gives this response with a 08 Trailer and error code 5052. The CMS has
performed an alpha search of its records and cannot locate the beneficiary's records.
Alpha search is the process of searching for the records based on the first six positions of
the surname. All beneficiaries with the same first six letters in their surnames are listed
with their HICNs. The system checks for possible matches, including the possibility that
numbers were transposed. This search is performed only if no match is found during the
search by HICN.
This code can be given in two forms:
1. With Trailer 01 - Trailer 01 will contain a possible corrected HICN. The A/B MAC
or DME MAC investigates the possible HICN and, if it believes the new HICN is for the
same beneficiary, it resubmits the claim with the new HICN to the Host. The CWF will
respond with the appropriate disposition code and any associated trailers for processing
the claim.
2. Without Trailer 01 - This response indicates that after performing the alpha search
operation, no match is found against the HICN submitted and CMS records. Since
Medicare eligibility cannot be established, A/B MACs and DME MACs shall return the
claim to the provider as unprocessable and take the following actions:
• 	A/B MACs (A, HHH) shall return to provider (RTP) Part A claims. A/B MACs (A,
HHH) shall not mail an MSN for these claims.
• 	A/B MACs (B) and DME MACs shall return as unprocessable Part B claims. A/B
MACs (B) and DME MACs shall use Group Code CO and Claim Adjustment
Reason (CARC) 140 (Patient/Insured health identification number and name do
not match). A/B MACs (B) and DME MACs shall not mail an MSN for these
claims.
• 	For assigned and unassigned Part B claims submitted by the beneficiary
on the Form CMS-1490S or Form CMS-1500, A/B MACs (B) and DME

MACs shall manually return the claim in accordance with Pub.100-04,
chapter 1, section 80.3.2 A. "Special Considerations."
20.3.3.3 - Disposition Code 52 (Beneficiary Record at another Host)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
• 	When CMS receives a request for transfer, it searches its Master File to determine
if the Beneficiary Record resides at another Host.
• 	The CMS first searches the record based on the HICN. If a match is found, and
the beneficiary has not already been assigned to a Host, CMS sends the records to
the requesting Host. After the Host receives the record, it can process the claim
from the MAC on its next cycle.
• 	If a match is found that indicates the beneficiary has been assigned to another
Host, CMS sends the requesting Host a code 52. The requesting Host then sends
the claim information to the receiving Host that has the Beneficiary Record.
• 	The requesting Host will give the processing MAC a code 52 and Trailer 08 with
a 5052 error code.
• 	The MAC holds the claim and resends (recycles) it in five working days to see if
there is a response waiting.
• 	If the response is present on the first recycle of the claim, the MAC finishes
processing the claim according to the response.
• 	If a response is not present, the MAC receives another disposition code 52 and the
claim is sent to the proper Host for processing.
• 	The MAC recycles the claim after another five working days, and continues
recycling the claim until it receives an approval, adjustment, or reject (AAR)
response, or until 45 working days have passed.
• 	After 45 working days have passed with no AAR response, the MAC reports the
problem to the Host through locally established reporting procedures.
20.3.3.4 - Disposition Code 53 (Record in CMS Alpha Match)
(Rev. 4047, Issued: 05-11- 18, Effective: 08-13-18, Implementation: 08-13-18)
• 	If CMS sends a claim to alpha search, it must send a disposition code 53 to the
Host. The Host puts a code 53 on its TNIF file.
• 	The Satellite receives code 53 and Trailer 08 with a 5052 error code on the next
recycle of the claim.
• 	The Satellite must recycle the claim 15 working days after receiving this code.

• 	If an AAR response is not received after the receipt of the third code 53 for the
same claim, the Satellite must deny the claim using the following messages:
MSN message 5.1: "Our records show that you do not have Medicare
entitlement under the number shown on this notice. If you do not agree,
please contact your local Social Security office."
Group Code CO, Claim Adjustment Reason Code (CARC) 16
(Claim/service lacks information or has submission/billing error(s) which
is needed for adjudication. Do not use this code for claims
attachment(s)/other documentation. At least one Remark Code must be
provided (may be comprised of either the NCPDP Reject Reason Code, or
Remittance Advice Remark Code that is not an ALERT.) Note: Refer to
the 835 Healthcare Policy Identification Segment (loop 2110 Service
Payment Information REF), if present), and Remittance Advice Remark
Code (RARC) N382 - Missing/incomplete/invalid patient identifier.
20.3.3.5 - Disposition Code 54 (Matched to Cross-referenced HICN)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The Host provides the MAC with disposition code 54 and Trailer 08 with error code 5052
when it discovers a cross-reference number in its own files for the name or number the
MAC submitted. Disposition Code 54 applies only to A/B MAC (B) or DME MAC-
submitted claims. The possible number and the new full name is returned to the MAC on
Trailers 1 and 10.
• 	The A/B MAC or DME MAC investigates the information provided and corrects
the information on the claim and resends it.
• 	If the MAC continues to receive a code 54, it contacts the Host through locally
established procedures.
20.3.3.6 - Disposition Code 55 (Personal Characteristic Mismatch)
(Rev. 4047, Issued: 05-11-18, Effective: 08-13-18, Implementation: 08-13-18)
The Host provides the Satellite with this disposition code and Trailer 08 with error code
5052 when it discovers a mismatch of the Health Insurance Claim Number (HICN) with
the beneficiary’s personal characteristics such as name, sex or date of birth.
If CWF rejects a claim and sends back disposition code 55 with the 08 trailer containing
Error Code 5052 when the beneficiary’s personal characteristics do not match the HICN
in accordance with the CWF matching criterion, contractors shall return the claim to the
provider as unprocessable with the identifying beneficiary information from the
submitted claim as follows:
A/B MACs (A, HHH) shall return to provider (RTP) Part A claims. These A/B MACs
shall not mail an MSN for these claims.

A/B MACs (B) and DME MACs shall return as unprocessable Part B provider
submitted claims. The A/B MACs (B) and DME MACs shall not mail an MSN
for these claims. When returning these claims as unprocessable, the shared
processing system shall use Claim Adjustment Group Code (Group Code) CO –
Contractual Obligation, Claim Adjustment Reason Code (CARC) 16 -
Claim/service lacks information or has submission/billing error(s) which is
needed for adjudication. Do not use this code for claims attachment(s)/other
documentation. At least one Remark Code must be provided (may be comprised
of either the NCPDP Reject Reason Code, or Remittance Advice Remark Code
that is not an ALERT.) Note: Refer to the 835 Healthcare Policy Identification
Segment (loop 2110 Service Payment Information REF), if present with
Remittance Advice Remark Codes (RARCs) MA27 - Missing/incomplete/invalid
entitlement number or name shown on the claim and N382 -
Missing/incomplete/invalid patient identifier.
For assigned and non-assigned Part B claims submitted by the beneficiary on the Form
CMS-1490S or Form CMS-1500, A/B MACs (B) and DME MACs shall manually return
the claim in accordance with Pub.100-04, Chapter 1, Section 80.3.2 A. "Special
Considerations."
20.3.3.7 - Disposition Code 56 (MBI/HICN Mismatch)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Specific to new Medicare Beneficiary Identifier (MBI) processing, disposition code 56
can come with any of the following three error codes:
1. With Error Code 5060 - MBI entered is not found on the CWF file.
2. With Error Code 5061 - HICN entered is not found on the CWF file.
3. With Error Code 5062 - HICN and Submitted MBI combination on the claim do not
belong to the same beneficiary.
A/B MACs shall return the provider claims as unprocessable. When returning these
claims as unprocessable, the shared processing system shall use Claim Adjustment Group
Code (Group Code) CO – Contractual Obligation, Claim Adjustment Reason Code
(CARC) 16 - Claim/service lacks information or has submission/billing error(s) which is
needed for adjudication. Do not use this code for claims attachment(s)/other
documentation. At least one Remark Code must be provided (may be comprised of either
the NCPDP Reject Reason Code, or Remittance Advice Remark Code that is not an
ALERT.) Note: Refer to the 835 Healthcare Policy Identification Segment (loop 2110
Service Payment Information REF), if present, and RARC N382:
Missing/incomplete/invalid Medicare beneficiary identifier.
20.3.4 – Claim Maintenance Records Basic Reply

(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
This informational record is sent in response to the Claim Maintenance Transaction
Record sent to the host it acknowledges the Host's receipt of the Claim Maintenance
Transaction Record and indicates any errors or informational data. If accepted, the claims
maintenance record is posted to CWF auxiliary database as submitted to the Host.
Following are the types of codes and other information associated with this record. These
codes are returned on Basic Reply Trailer 08.
• 	Disposition codes; SP, RD, CM, BO, EP, PA or IV, as appropriate
• 	Transaction Error codes; The error codes indicate the errors in consistency found
on the transaction
• 	Basic Reply. Trailer 08 containing up to four error codes
20.3.5 - Unsolicited Response/Informational Unsolicited Response
(UR/IUR)
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
CWF system also returns unsolicited response/informational unsolicited response to
MACs when the processing of a current claim results in the need for action on a
previously paid claim. Generally, changes in a beneficiary’s entitlement or utilization
history information on Beneficiary trigger UR/IUR response. The information used to
process the earlier claim is no longer accurate and the claim must be corrected.
CWF typically sends these responses to MACs in an immediate reaction to claims the
contractor has recently submitted. An unsolicited response is an instruction from CWF to
act on a previously paid claim days or even months after the paid claim received its
original CWF response.
• 	Unsolicited response (UR): CWF cancels or adjusts a claim in CWF history and
sends the information in basic reply trailers (08 and 24) to the MACs to take
action.
• 	Informational unsolicited response (IUR): CWF system takes no action on a
claim in history, but sends basic reply trailers (08 and 24) to MACs to perform
corrective action.
30 - Reviewing the Beneficiary and Claim(s) Information
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
30.1 - Online Health Insurance Master Record (HIMR) Display
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Beneficiary entitlement and utilization data on all nine CWF databases is available online
through the HIMR transaction. It allows the MAC to do further investigation about a
claim or inquire about beneficiary entitlement and utilization status. This function is a
display of information only. The user at the MAC site cannot make changes to the
screens accessed through HIMR.

This information is applicable only to MACs and Host site staff.
30.2 - CWF Provider Queries - Online Eligibility Information for
Medicare Part A Providers
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The CWF will provide access to the Part “A” Eligibility System. MAC and/or Medicare
Part A Providers can request the beneficiary master information from the CWF host via
HIQA/ELGA and HIQH/ELGH inquiry screens to obtain the information. The
information can also be requested though unformatted query, HUQA. These functions are
for display of information only. The user at the MAC and/or Provider site cannot make
changes to the screens accessed through eligibility system.
30.3 – Online Reporting (ORPT) System Display
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The CWF will provide access to online reporting system (ORPT) to MAC’s. The ORPT
Reporting System will locate data for a designated Contractor and display it on the
screen. CWF identifies the location of MAC’s reporting data at remote Hosts based on
information available in the local Host's Contractor table records. This function is a
display of information only. The user at the MAC site cannot make changes to the
screens accessed through ORPT system.
40 - Requesting Assistance in Resolving CWF Utilization
(Rev. 1, 10-01-03)
B3-6008
40.1 - Requesting Assistance in Resolving CWF Utilization Problems
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
This section applies only to MACs; it does not apply to providers.
In the normal course of claims processing activities, MACs can expect to encounter
problems involving the CWF Claim Record and/or basic reply record procedures. The
action necessary to resolve the problem depends upon the problem identified. For
utilization problems and/or HICR requests, the MAC enters the issue into the secure
online inquiry system, Host Request Inquiry (HURQ), provided by the CWF Host, and
sends all master beneficiary, summary history, and inpatient summary history screen-
prints for the beneficiary to the CWF HICR contractor for investigation. The MAC takes
the following steps:
• 	Put the error code causing the problem in the upper right-hand corner of the
Beneficiary Master screen print;
• 	Mark on all of the screen prints exactly what the problem is and what is believed
to be the correction needed;

• 	The MAC (contractor) sends these marked screen prints to the CWF HICR
contractor. They coordinate with the other contractor to determine who needs to
correct the problem; and
• 	The CWF HICR contractor will investigate the problem and correct it. If a
response is not received within 45 days of mailing the request for assistance, the
contractor sends a second request marked "SECOND REQUEST."
NOTE: Congressional requests are faxed to the CWF HICR contractor. Faxes must be
reviewed and corrective action taken within 24-48 hours of receipt.
For problems involving the Host CWF Site, the MAC utilizes the HICR transaction. This
transaction provides the Host CWF site a method of creating transactions that correct the
local database.
40.2 - Social Security Administration (SSA) Involvement
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
SSA maintains the Master Beneficiary Record (MBR) from which the Health Insurance
(HI) Master Record is established. The CWF's eligibility record is accreted from this HI
Master Record. The HI Master Record is updated periodically from a variety of sources,
including the MBR, and in turn updates the Host maintaining the CWF record. However,
errors occur where the MBR fails to correctly update the HI Master Record or where the
HI Master Record fails to correctly update the CWF record.
If the problem is caused by difficulties in determining the beneficiary's correct
entitlement status, the A/B MAC or DME MAC must request assistance of the SSO. The
SSO is responsible for processing the case. Examples of situations covered by this
procedure are:
• 	Problems involving Railroad Retirement Board (RRB) jurisdiction, i.e., the RRB
has jurisdiction of the beneficiary's Medicare, and the claim was erroneously
referred to the area A/B MAC (B);
• 	Evidence that a beneficiary has utilization under more than one health insurance
claim number (HICN), but the MAC is not aware of any cross-reference action
taken by CMS; or
• 	Assistance is needed to obtain or verify a beneficiary's name and/or MBI. (See
specific procedures in §20.3.3.6 under disposition code 55.)
In the event the SSO is unable to resolve the entitlement problem, e.g., a disposition code
55 is received after SSA verified the beneficiary's name and/or MBI, the MAC requests
assistance from the RO. It includes complete details of the nature of the problem and a
description of its efforts to resolve it.

40.3 - Critical Case Procedure - Establishing Entitlement
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The MAC uses the "critical case" procedure (see §40.4, below) to expedite the processing
of claims which have been delayed because of an error in the beneficiary's CWF Master
Record. The "critical case" procedure provides speedy correction of the master record.
The MAC uses this procedure when there is an error in the CWF Master Record, which
prevents the receipt of an approval disposition code on the basic reply record. This may
occur when one of the following conditions exists:
• 	The MAC is unable to make payment on a claim even though the beneficiary
apparently has entitlement because CWF transmitted a Basic Reply Record with
an inaccurate or repeated disposition code of "50," "51," 52," "53," "54," "55,"
"57," "58," "59," "60," "61," "AB," "CI," "ER," "UR," "CR;" or
• 	The MAC received a Basic Reply Record and the recycled CWF Claim Records
have not received a disposition code, which permits processing the claim to
payment or denial.
40.4 - Referral of Critical Cases to the Regional Office
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When the MAC identifies a claim meeting the criteria listed below, it contacts the RO via
established referral methods. The MAC identifies the beneficiary by name and MBI,
specifies the nature of the problem, states that the criteria are met, and gives the dates of
all actions. The MAC provides all available supporting documentation. Examples of
such documentation are:
• 	Social Security Administration's (SSA) reply to Form CMS-1980 in the case of
entitlement questions; and
• 	A copy of the Health Insurance Master Record Entitlement Status Query (ESQ)
received from an SSA District Office.
The criteria are:
• 	Two follow-ups have been made to the Social Security Office (SSO) and the
CWF Master Record has not been corrected;
• 	At least 60 days have elapsed since the correction procedures were initiated;
• 	A serious hardship to the beneficiary or a public relations problem has developed;
• 	Corrections or changes to HMO termination dates are necessary; and
• 	The SSO response indicates that both the MBR and HI Master Records are
correct.
The MAC marks the information "CRITICAL CASE." The MAC flags the file for special
handling and expedites the claim as soon as the reply is received.

The MAC must diary the case for 30 calendar days. By that time the RO should have a
response and advise the MAC. If the MAC receives a positive basic reply record before
hearing from the RO, it notifies the RO.
50 - Requesting or Providing Assistance to Resolve CWF Rejects
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When a MAC has difficulty processing a bill because a prior bill was incorrectly
processed and posted to CWF by another MAC (A/B MAC or DME MAC), the two A/B
MACs or DME MACs must work together to resolve the error. Where help is needed
from another A/B MAC or DME MAC, the submitting MAC requests assistance from the
contractor whose bill was processed incorrectly. The A/B MAC or DME MAC that
processed the bill is identified in the CWF reject trailer.
50.1 - Requesting A/B MAC or DME MAC Action
(Rev. 3468, Issued: 02-18-16, Effective: 12-02-15, Implementation: 12-02-15)
The requesting A/B MAC or DME MAC furnishes the assisting A/B MAC or DME MAC
with sufficient information to identify the issue and perform the necessary resolution
actions. The data shown on the Request for Assistance Form (see Exhibit 1) is needed.
This format must be used when designing a form letter so that both the requesting A/B
MAC or DME MAC's address and the assisting A/B MAC or DME MAC's address will be
visible through a window envelope. A separate page is used for each request to enable
the assisting A/B MAC or DME MAC to return each claim as completed instead of
holding claims until all claims on a request are completed. The requesting A/B MAC or
DME MAC enters its request after "The following action is requested." The requesting
A/B MAC or DME MAC provides claim-identifying information as shown. The
requesting A/B MAC or DME MAC adds information to help it associate the response
with its pending record, if needed.
If a response has not been received within 30 calendar days of the request, the requesting
A/ B MAC or DME MAC sends a follow-up request. If no response is received within an
additional 15 days, follow-up with the RO responsible for the assisting A/B MAC or DME
MAC. A status report indicating and defining problems that prevent processing of the
request is considered a response in deciding whether to follow-up with the RO.
In addition, the requesting A/B MAC or DME MAC considers whether an interim
payment to the provider without CWF approval is appropriate. (See §60 of this chapter
for procedures for paying without CWF approval.)
50.2 - Assisting A/B MAC or DME MAC Action
(Rev. 3468, Issued: 02-18-16, Effective: 12-02-15, Implementation: 12-02-15)
Upon receipt of a request for assistance, the assisting A/B MAC or DME MAC adjusts or
cancels the posted bill, as appropriate, and informs the requesting A/B MAC or DME
MAC by annotating the request form (under explanation of action taken by assisting A/B

MAC or DME MAC) with a description of its action (e.g., adjustment cleared CWF
(date), current dates of service are __________.)
The assisting A/B MAC or DME MAC completes corrective actions within 30 calendar
days of receiving the request. If it cannot complete action within 30 days, provide a
status reply explaining the reasons on a copy of the request form. The assisting A/B MAC
or DME MAC sends a copy of the reply to the RO.
The assisting A/B MAC or DME MAC uses the request form on all correspondence to the
requesting A/B MAC or DME MAC to facilitate association of its response with the
pending action.
50.3 - Format for Requesting Assistance From Another A/B MAC or
DME MAC on CWF Edits
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Exhibit 1 contains the required format for requesting assistance. The requesting A/B
MAC or DME MAC uses that format in designing its form letter so that both its address
and the assisting A/B MAC or DME MAC's address will be visible through a window
envelope. The requesting A/B MAC or DME MAC completes all data elements. Note that
the form is designed so that a standard number 10 - 4 1/8 by 9 1/2 inch window envelope
can be used for your request. The assisting A/B MAC or DME MAC may refold the form
and use the same size window envelope in its reply. The requesting A/B MAC or DME
MAC enters its address in the bottom address space, and uses the following in the top
address space:
A/B Medicare Administrative Contractor or DME MAC (as applicable) or
Name of Contractor
PO Box or Street Address
City, State, ZIP Code
Exhibit 1 - Request for Assistance
Date___________
┌ 	┐
To: 	Request: 	___ First
___ Follow up
___ RO copy
└ 	┘
Date of First Request 	_______________
(If Follow up)
We request assistance in resolving CWF reject, edit code_______________________
enter code #
The following action is requested:

IDENTIFYING INFORMATION
______________________________ 	___________________________________
Medicare beneficiary identifier 	Beneficiary Name
______________________________ 	______________________________
Your ICN 	Your Provider
______________________________ 	______________________________
From Date 	Through Date
Explanation of action taken by assisting A/B MAC or DME MAC:
REQUESTOR INFORMATION
__________________________________
Claim #
__________________________________
Dates of Service
Response Date 	__________________________________
____ Final 	Provider
____ Status 	__________________________________
Other
Return To:
Requesting Contractor Name
Address Line 1 	__________________________________
Address Line 2 	Contact Person and Phone #
Address Line 3 (if needed)
60 - Paying Claims Outside of CWF
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The CWF approves each claim before it is paid. However, there may be special
circumstances when it is necessary to pay claims outside the CWF/CWF system. The
CMS will notify the A/B MAC or DME MAC of these instances. They include, but may
not be limited to:
• 	New coverage policies are enacted by Congress with effective dates that preclude
making the necessary changes to CWF timely; and,
• 	Errors are discovered in CWF that cannot be corrected timely. All A/B MACs
and DME MACs are responsible for reporting CWF problems to their host sites.
60.1 - Requesting to Pay Claims Outside of CWF
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)

A/B MACs or DME MACs may also request approval from CMS in specific situations to
pay claims without CWF approval. Examples of such situations are:
• 	Other A/B MACs or DME MACs cannot complete action to remove an
impediment that blocks a contractor from processing of a claim; and/or
• 	A systems error cannot be corrected timely, and the provider's cash flow will be
seriously endangered.
• 	Administrative Law Judge (ALJ) decisions, court decisions, and CMS instructions
in particular cases may necessitate that payment be made outside the normal CWF
process.
A/B MACs or DME MACs shall obtain approval from CMS to pay a claim without CWF
approval prior to processing that claim outside the CWF/CWF system. A/B MACs and
DME MACs shall submit a written request to their CMS Contracting Officer
Representative (COR) for approval to make payment without CWF approval. Such
requests shall be submitted by facsimile transmission or via the Internet. To ensure the
protection of the Personal Health Information (PHI) and Personally Identifiable
Information (PII) contained in contractor requests to pay claims without CWF approval,
contractors shall encrypt their E-mail submitted requests.
A/B MACs or DME MACs shall provide the following information to their CMS COR
when requesting to pay a claim without CWF approval:
a) 	A/B MAC or DME MAC’s Internal Claim Control Number,
b) 	Medicare beneficiary identifier,
c) 	Beneficiary Name,
d) 	Provider Number (National Provider Identification (NPI) Number),
e) 	From and To Date of Service,
f) 	Procedure Code(s),
g) 	Total Charges,
h) 	Amount to be Paid,
i) 	CWF Error Code/Condition Preventing Payment (including error code definition),
and
j) 	Rationale for Paying the Claim Outside the CWF/CWF System.
60.2 - Procedures for Paying Claims Outside of CWF
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Before a claim can be paid outside the CWF/CWF system, A/B MACs or DME MACs
shall obtain approval from their CMS COR, or his/her designee. In all instances
involving payment outside the CWF/CWF system, A/B MACs or DME MACs shall apply
the following procedures, unless otherwise specified:

• 	Submit the claims with an "X" in the tape-to-tape flag, and the system will
determine payment as if the payment were final. Inpatient PPS payments shall be
processed through MCE, Grouper and Pricer. Hospice payments shall be made
using the appropriate hospice rate. ESRD visits shall be paid using the composite
rate. The appropriate fee schedules or interim rates shall be used. Deductible and
coinsurance shall be applied based on the most current data available. Do not
apply the CMS-prescribed percent reduction applicable to accelerated payment.
• 	Follow shared system procedures to avoid sending a claim to the CWF at time of
payment, but shall also maintain a record for later submission.
• 	Pay interest accrued through the date payment is made on clean claims. Do not
pay any additional interest.
• 	Maintain a record of payment and implement controls to be sure that duplicate
payment is not made (i.e., when the claim record is updated to CWF or in
response to a duplicate request by the provider).
• 	Monitor the CWF to determine when the impediment to CWF processing is
removed. Additionally, A/B MACs and DME MACs shall update the CWF when
the impediment is removed so that the actual payment date outside the CWF is
shown in the scheduled payment data field.
• 	Consider the claim processed for workload and expenditure reports when it is
paid.
60.3 – Contractor Monthly Reports of Claims Paid Outside of CWF
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
A/B MACs and DME MACs shall submit, by the 20th day of the following month, a
monthly report of all claims paid without CWF approval to their CMS COR. A/B MACs
and DME MACs shall encrypt reports submitted via the Internet to ensure the protection
of the Personal Health Information (PHI) and Personally Identifiable Information (PII)
contained in these reports.
The monthly reports of claims paid outside the CWF/ CWF system shall include
summary data for each edit code showing claim volume and payment. The reports shall
also identify the claims and summary edit code volume and payment data as to whether it
is a Part A or Part B Service. The monthly reports shall provide the data listed below for
each claim paid without CWF approval for that reporting month:
a) 	Medicare beneficiary identifier,
b) 	Beneficiary Name,
c) 	Provider Number (National Provider Identification Number (NPI),
d) 	From and to Date of Service,
e) 	Total Charges,

f) 	Amount Paid,
g) 	Paid Date, and
h) 	CWF Error Code/Condition Preventing Payment.
70 - Change Control Procedures
(Rev. 4088, Issued: 07-13-18, Effective: 08-14-18, Implementation: 08-14- 18)
The CWF software is changed quarterly to accommodate revised CMS requirements, new
provisions of law, to correct errors, or to enhance the system. A/B MACs and DME
MACs may also request changes to CWF through certain change control procedures.
70.1 - MAC Procedure
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
When a MAC has a recommendation for software changes, it follows the change control
process below:
• 	Enter change requests into the CWF Information Management System
(INFOMAN).
• 	After entering change requests into INFOMAN, submit all supporting
documentation to the Host for review and forwarding to both CMS and the CWF
Maintenance Contractor (CWFM) for consideration and entry into the Change
Control System.
• 	Monitor progress of all changes submitted from your site through INFOMAN.
• 	Review implementation of all changes from your own site to insure that needs are
addressed.
70.2 - Process Flow of a Change Request
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
• 	Complete a CWF Change Request (CR) through INFOMAN. When the CR is
created a CR number will automatically be assigned.
• 	Forward three copies of all supporting documentation to the Host site. Include the
CR number on all documentation. The Host will review it and the CR for
accuracy, completeness, and relevance. The review may also determine whether a
problem reported is a CWF problem or a problem with the MAC's software.
• 	When the Host approves the CR, it releases the Change Request to the CWFM
and to the CMS central office (CO) in accordance with current procedures.

• 	CMS and the CWFM review the Change Requests as received throughout the
month.
• 	CMS distributes all change requests to the appropriate CMS component for
review and approval as they are received.
• 	A monthly Change Control meeting of CMS and CWFM staff is held to schedule
approved Change Requests for release.
• 	Following the meeting, the CWFM enters approval and priority status of all
Change Requests into the automated system. As work progresses, the CWFM
enters the status of all changes, Quality Assurance (QA) activities and work
performed.
70.3 - Handling Emergency Problems and Problems With Recent CWF
Releases
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
A problem is considered an emergency if a large number of claims are paid incorrectly,
cannot be paid, or the MAC/Host system abnormally ends (abends). When an emergency
occurs, the MAC follows these procedures:
1. 	The MAC will convey information about the emergency to the Host immediately.
The MAC must be able to submit documentation of the problem.
2. 	The Host will report the problem to the CWFM immediately via CWFM customer
service. The service is available 24 hours a day, 7 days a week.
3. 	During business hours, CWFM will respond immediately. After business hours,
CWFM will contact the Host within one hour of report of the problem.
70.4 - Distribution of "CWF Change Control" Reports
Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
• 	CWFM distributes a monthly "Status of CWF Changes" report and "Schedule of
CWF Changes" report to all Host sites, CMS ROs, and CMS CO staff.
• 	Each Host site distributes the reports to its MAC sites within three working days
of receipt.
70.5 - Channels of Communication
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
All MAC inquiries should be made to the Host staff, according to locally established
procedures.

70.6 - Schedule of CWF Software Releases
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
• 	Regular Releases - Scheduled quarterly releases normally contain changes due to
both routine maintenance and new CMS mandates. Other changes included in a
regular release shall be in response to issues submitted through the CWF Change
Control Process or Sustainability CR’s requested by CMS.
• 	Emergency Releases - Emergency off-quarter releases shall be in response to a
critical problem prioritized as a P1 or P2, which causes a delay in processing, or
causes claims not to be paid or paid incorrectly. An effective date for an
emergency release shall be determined in advance by the CMS CWF team.
Generally, an emergency release shall be distributed by the CWFM via
telecommunications facilities and installed immediately by the CWF Hosts with
the formal approval of CMS. The CWFM shall open a problem into the
INFOMAN system for error tracking purposes when the emergency is confirmed.
Technical assistance shall include analyzing requirements and debugging
programs, data, or file structures that result in operational problems or that
interferes with normal operational processing. The CWFM shall review, analyze,
develop, and document each problem. The CWFM shall group problems
according to functionality for the purpose of updating, correcting, modifying, and
enhancing the CWF system software.
• 	Special Releases - Special off-quarterly releases shall be provided as needed in
response to situations which are of a particular or unusual date dependent nature.
These releases shall be provided, for example, in response to a special project
approved by CMS that may be of a high priority nature. The CWFM shall not
move special releases to production without the permission of CMS. No less than
24 hours prior to the release moving to production, the CWFM shall send an
email to the CMS CWF team requesting approval for implementing the special
release. The email shall list all CRs and problem fixes scheduled for
implementation.
• 	Priority Releases - Priority off-quarter releases are scheduled in response to
resolve as a follow-up to incomplete or inaccurate changes that are made due to
any previous software release. They generally arise from problems in the system
that was not evident prior to a release being implemented. Priority releases are
generally scheduled bi-weekly, except during the final month of each quarter,
where minimal changes are permitted. A production release date for a priority
release shall be determined in advance by CMS CWF team, the CWFM and
implemented with the formal approval of CMS. No less than 24 hours prior to the
release moving to production the CWFM shall send an email to the CMS CWF
team requesting approval for implementing the priority release. The email shall
list all CRs and problem fixes scheduled for implementation.
80 - Processing Disposition and Error Codes
(Rev. 4088, Issued: 07-13-18, Effective: 08-14-18, Implementation: 08-14- 18)

The results of CWF processing are communicated through a set of codes categorized as
either disposition or error codes. There are specific disposition codes for inquiry,
transfer/not in file request, and each claim type. Claims have consistency, utilization,
A/B crossover, and duplicate error codes.
Transactions for End Stage Renal Disease (ESRD), Medicare Secondary Payer (MSP),
and Certificate of Medical Necessity (CMN) error codes, as still applicable, are also
available.
If the Host rejects a claim, the A/B MAC or DME MAC shall either adjudicate the claim
systematically or suspend the claim and review it. After the review is complete and
corrections made, the A/B MAC or DME MAC resubmits the claim with an indication
that a review was performed and corrections made.
80.1 - Disposition Codes
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Each reply record will contain a disposition code that indicates the action taken on the
bill by the Host and what action the MAC’s should take next.
Below are the list of common disposition codes applicable to CWF processing
01 -Approved
03 -Cancel Accepted
04 -Accrete History (Action Code ‘07’ or Entry Code ‘09’) Accepted
50 -Not in file
51 -Not in file on CMS batch system
52 -Master Record housed at another CWF site
53 -Record in CMS alpha match
54 -Matched to Cross-referenced HICN
55 -Does not match master record
56 -MBI/HICN mismatch
60 -I/O Error on database
61 -Cross reference/database problem
AA -Auto Adjust error
AB -Transaction caused CICS ABEND
BO -Beneficiary Other Information (HUBO) edits
CI -CICS processing problem
CM -Certified Medical Necessity (HUCM) Edits

CR –A/B Crossover Reject
ER -Consistency Edit Reject
EP -Libby Montana (HUEP) project edits
IV -Intravenous Immune Globulin transaction (HUIV) edits
PA -Prior Authorization transaction (HUPA) edits
RD -End Stage Renal (HURD) transaction edits
SP -Medicare Secondary Payer transaction (HUSP) edits
UR -Utilization Reject
80.2 - Error Codes
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
The results of CWF error processing is controlled by different set of components. There
are specific error codes for each claim type and maintenance transactions. Claims have a
Consistency, Utilization, A/B Crossover, and Duplicate error codes.
Transactions for Medicare Secondary Payer (MSP), End Stage Renal Disease (ESRD),
Certificate of Medical Necessity (CMN), Beneficiary other insurance (BOI), Libby
Montana (HUEP), Prior Authorization (HUPA),and IVIG error codes are also available.
Below are the list of high level error functions performed during the CWF processing
1. 	Inpatient, SNF, Outpatient, Home Health, and Hospice consistency edits,
2. 	Part B/DMEPOS consistency edits,
3. 	Entitlement edits,
4. 	Duplicate edits,
5. 	Inpatient, SNF, Outpatient, Home Health, and Hospice utilization edits,
6. 	Part B/DMEPOS utilization edits,
7. 	A/B Crossover edits,
8. 	Medicare Secondary Payer (MSP) consistency/utilization edits,
9. 	MSP transaction (HUSP) edits,
10. Certified Medical Necessity (CMN) consistency/utilization edits,
11. CMN transaction (HUCM) edits,
12. End Stage Renal Decease (HURD) consistency/utilization edits,
13. ESRD transaction (HURD) edits,
14. Beneficiary Other Information (BOI)/Claim based crossover edits,
15. BOI transaction (HUBO) edits,
16. Libby Montana (HUEP) project edits,
17. Prior Authorization (PRAU) consistency/utilization edits,
18. PRAU transaction (HUPA) edits,
19. Immune Globulin (IVIG) consistency/utilization edits,
20. IVIG transaction (HUIV) edits, and
21. BDS/FPS and other processing edits.

80.3 - Beneficiary Other Insurance Information (HUBO) Maintenance
Transaction Error Codes
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Effective January 2, 2007, the CWF shall accept and process a HUBO transaction that
either updates an existing Beneficiary Other Insurance (BOI) auxiliary record or adds a
new BOI auxiliary record occurrence.
If the CWF receives an incoming HUBO transaction whose COBA identification number
(ID) and ‘beneficiary supplemental eligibility-from date’ (CCYYMMDD) match the
equivalent elements within an existing BOI auxiliary record, it shall overlay the existing
record with the incoming record. However, if the CWF receives an incoming HUBO
transaction whereby the COBA ID and ‘beneficiary supplemental-from date’ do not match
the equivalent elements within an existing BOI auxiliary record, it shall create a new BOI
auxiliary record occurrence.
For purposes of applying COBA eligibility files to the BOI auxiliary file, the CWF
maintainer shall redefine Action Type ‘0- Add’ as ‘1-Add/Update.’ For purposes of
applying COBA eligibility files to the BOI auxiliary record, the CWF shall now accept and
process only two Action Types—‘1 - Add/Update’ and ‘2 – Delete’—from the BCRC as
part of the COBA crossover process.
The CWF shall continue to apply the applicable ‘BO’ edits that would relate to add/update
or delete actions accomplished via the HUBO transaction.
80.4 - Consolidated Claims Crossover Process
(Rev. 11396, Issued:05-04-2022, Effective:10-01-2022, Implementation:10-03-2022)
A. The Mechanics of the CWF Claims Selection Process and BOI and Claim-based
Reply Trailers
1. CWF Receipt and Processing of the Coordination of Benefits Agreement Insurance File
(COIF)
Effective July 6, 2004, the Benefits Coordination & Recovery Center (BCRC) began to
send copies of the Coordination of Benefits Agreement Insurance File (COIF) to the nine
CWF host sites on a weekly basis. The COIF will contain specific information that will
identify the beneficiaries other health insurance, also known as the COBA trading partner,
including name, COBA ID, address, and tax identification number (TIN). It will also
contain each trading partner’s claims selection criteria exclusions (claim or bill types that
the trading partner does not want to receive via the crossover process) along with an
indicator (Y=Yes; N=No) regarding whether the trading partner wishes its name to be
printed on the Medicare Summary Notice (MSN).
The CWF shall load the initial COIF submission from the BCRC as well as all future
weekly updates.
Upon receipt of a claim, the CWF shall take the following actions:

a. 	Search for a COBA eligibility record on the BOI auxiliary record for each beneficiary,
unless there is a COBA ID in range 55000 through 55999 present on the incoming HUBC
or HUDC claim (which identifies Medigap claim-based crossover), and obtain the
associated COBA ID(s) NOTE: There may be multiple COBA IDs;
b. 	Refer to the COIF associated with each COBA ID (NOTE: CWF shall pull the COBA
ID from the BOI auxiliary record) to obtain the COBA trading partner’s name and claims
selection criteria;
c. 	Apply the COBA trading partner’s selection criteria; and
d. 	Transmit a BOI reply trailer 29 to the A/B MAC or DME MAC only if the claim is to be
sent, via 837 COB flat file or National Council for Prescription Drug Programs (NCPDP)
file, to the BCRC to be crossed over. (See Pub.100-04, Chap. 28, §70.6 for more
information about the claim file transmission process involving the A/B MAC or DME
MAC and the BCRC.)
Effective with the October 2004 systems release, CWF shall read the COIF submission to
determine whether a Test/Production Indicator “T” (test mode) or “P” (production mode) is
present. CWF will then include the Test/Production Indicator on the BOI reply trailer 29
that is returned to the A/B MAC or DME MAC. (See additional details below.)
Effective with July 7, 2009, at CMS’s direction, the BCRC modified the COIF so that the
“Test/Production” indicator, originally created as part of the October 2004 release, is
renamed the “4010A1 Test/Production indicator” and a new field, the “NCPDP-5.1
Test/Production indicator,” is also reflected. In turn, CWF shall 1) accept and process the
BCRC-generated modified COIF on a weekly basis; and 2) accept the following values
within the two newly defined COIF fields: “N” (format not in use for this trading partner);
“P” (trading partner in production); and “T” (trading partner in “test” mode). CWF shall
also modify the BOI reply trailer (29) to reflect these changes, as further specified under
“BOI Reply Trailer 29 Processes” below.
2. BOI Reply Trailer 29 Processes
For purposes of eligibility file-based crossover, if CWF selects a claim for crossover, it
shall return a BOI reply trailer 29 to the A/B MAC or DME MAC. The returned BOI reply
trailer 29 shall include, in addition to COBA ID(s), the COBA trading partner name(s), an
“A” crossover indicator that specifies that the claim has been selected to be crossed over,
the insurer effective and termination dates, and a 1-digit indicator [“Y”=Yes; “N”=No] that
specifies whether the COBA trading partner’s name should be printed on the beneficiary
MSN. Effective with the October 2004 systems release, CWF shall also include a 1-digit
Test/Production Indicator “T” (test mode) or “P” (production mode) on the BOI reply
trailer 29 that is returned to the A/B MAC or DME MAC.
Effective with July 7, 2009, CWF shall modify the BOI reply trailer (29) to rename the
existing Test/Production indicator as “4010A1 Test/Production indicator” and rename the

NCPDP Test/Production indicator as “NCPDPD0 Test/Production indicator.” In addition,
CWF shall include a new 1-byte field “NCPDP51 Test/Production indicator” as part of the
BOI reply trailer (29).
B. MSN Crossover Messages
Beginning with the October 2004 systems release, when an A/B MAC or DME MAC
receives a BOI reply trailer 29 from CWF that contains a Test/Production Indicator “T”
(test mode), it shall ignore the MSN Indicator provided on the trailer. Instead, the A/B
MAC or DME MAC shall follow its existing procedures for inclusion of trading partner
names on MSNs for those trading partners with whom it has existing Trading Partner
Agreements (TPAs).
Beginning with the October 2004 systems release, when an A/B MAC or DME MAC
receives a BOI reply trailer 29 from CWF that contains a Test/Production Indicator “P”
(production mode), it shall read the MSN indicator (Y=Yes, print trading partner’s name;
N=Do not print trading partner’s name) returned on the BOI reply trailer 29. (Refer to
Pub.100-4, chapter 28, §70.6 for additional details.)
Effective January 5, 2009, when CWF returns a BOI reply trailer (29) to an A/B MAC or
DME MAC that contains only a COBA ID in the range 89000 through 89999, the shared
system shall suppress all crossover information, including name of insurer and generic
message#35.1, from all beneficiary MSNs. (See chapter 28, §70.6 for details regarding
additional A/B MAC and DME MAC requirements.)
In addition, the A/B MAC or DME MAC shall not issue special provider notification
letters following its receipt of BCRC Detailed Error Reports when the claim’s associated
COBA ID is within the range 89000 through 89999 (see chapter 28, §70.6.1 for more
details.)
C. Electronic Remittance Advice (835)/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 835 Electronic Remittance Advice or other provider remittance advice(s) that is/are
in production. A/B MACs and DME MACs shall, however, populate the 835 ERA (or
provider remittance advice(s) in production) with required crossover information when
they have existing agreements with trading partners.
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:

1. Record 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.]
2. Update the 2100 Loop (Crossover Carrier 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.
If the 835 ERA is not in production and the A/B MAC or DME MAC receives a “P”
Test/Production Indicator, the A/B MAC or DME MAC shall use the information provided
on the BOI reply trailer (29) to populate the existing provider remittance advices that it has
in production.
Effective January 5, 2009, if CWF returns only a COBA ID range 89000 through 89999
on a BOI reply trailer (29) to an A/B MAC or DME MAC, the associated shared system
shall suppress all crossover information (the entire 2100 loop) on the 835 ERA.
Effective 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 has
signed a national COBA), CWF shall sort the COBA IDs and trading partner names in the
following order:
1) Eligibility-based Medigap (30000-54999); 2) Claim-based Medigap (55000-59999); 3)
Supplemental (00001-29999); 4) Other Insurer (80000-80213); 5) Other Insurer (80215-
88999); 6) CHAMPVA (80214); 7) TRICARE (60000-69999); 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 item 24 in the BOI Auxiliary File table
above), CWF shall sort numerically within the same range.
3. CWF Treatment of Non-assigned Medicaid Claims
When CWF receives a non-assigned Medicare claim for a beneficiary whose BOI auxiliary
record contains a COBA ID with a current effective date in the Medicaid eligibility-based
range (70000-77999), it shall reject the claim by returning edit 5248 to the A/B MAC (B)

shared system only when the Medicaid COBA trading partner is in production mode
(Test/Production Indicator=P) with the BCRC. At the same time, CWF shall only return a
Medicaid reply trailer 36 to the A/B MAC (B) that contains the trading partner’s COBA ID
and beneficiary’s effective and termination dates under Medicaid when the Medicaid
COBA trading partner is in production mode with the BCRC. CWF shall determine that a
Medicaid trading partner is in production mode by referring to the latest COIF update it
has received.
If, upon receipt of CWF edit 5248 and the Medicaid reply trailer (36), the A/B MAC (B)
determines that the non-assigned claim’s service dates fall during a period when the
beneficiary is eligible for Medicaid, it shall convert the assignment indicator from “non-
assigned” to “assigned” and retransmit the claim to CWF. After the claim has been
retransmitted, the CWF will only return a BOI reply trailer to the A/B MAC (B) if the claim
is to be sent to the BCRC to be crossed over.
Effective with October 1, 2007, CWF shall cease returning an edit 5248 and Medicaid
reply trailer 36 to a DME MAC. In lieu of this procedure, CWF shall only return a BOI
reply trailer (29) to the DME MAC for the claim if the COBA Insurance File (COIF) for
the State Medicaid Agency indicates that the entity wishes to receive non-assigned claims.
NOTE: Most Medicaid agencies will not accept such claims for crossover purposes.
If CWF determines via the corresponding COIF that the State Medicaid Agency does not
wish to receive non-assigned claims, it shall exclude the claim for crossover. In addition,
CWF shall mark the excluded claim with its appropriate claims crossover disposition
indicator (see §80.5 of this chapter for more details) and store the claim with the
information within the appropriate Health Insurance Master Record (HIMR) detailed
history screen.
DME MACs shall no longer modify the provider assignment indicator on incoming non-
assigned supplier claims for which there is a corresponding COBA ID in the ‘Medicaid’
range (70000-77999).
4. Additional Information Included on the HUIP, HUOP, HUHH, HUHC, HUBC and
HUDC Queries to CWF
Beneficiary Liability Indicators on Part B and DMAC CWF Claims Transactions
Effective with the January 2005 release, the Part B and DME MAC shared systems shall be
required to 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) will be at the header or claim level rather than at the line level.
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. 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” shall be included in a field on the HUDC query that is separate from the
fields used to indicate whether a beneficiary is liable for all services denied on his/her
claim.
The CWF shall read the new indicators passed via the HUBC or HUDC queries for
purposes of excluding denied services on claims with or without beneficiary liability and
NCPDP claims.
Beneficiary Liability Indicators on Part A CWF Claims Transactions
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 or N).
As A/B MACs (A, 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 (A, 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.
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’).
CWF shall deploy the same logic for excluding Part A fully denied ‘original’ and
‘adjustment’ claims with or without beneficiary liability as it now utilizes to exclude fully
denied ‘original’ and ‘adjustment’ Part B and DMEPOS claims with and without
beneficiary liability, as specified elsewhere within this section. As of January 4, 2010,
CWF shall read action code 8, in addition to action code 1, in association with incoming
fully denied original HUIP and HUOP claims. CWF shall continue to read action code 1
for purposes of excluding all other fully denied original HUHH and HUHA claims. (See
items J and K within this section for more specifics regarding revised logic for exclusion
of fully denied HUIP and HUOP adjustment claims.)
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 (A, HHH) sends values other than ‘L’ or ‘N’ 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 (A, HHH) or DME MAC for correction.
Following receipt of the CWF rejection, the A/B MAC (A, HHH) shall change the
incorrect value placed within the newly defined beneficiary liability field and retransmit
the claim to CWF.
5. Modification to the CWF Inclusion or Exclusion Logic for the COBA Crossover
Process
Beginning with the October 2006 release, the CWF or its maintainer shall modify its
COBA claims selection logic and processes as indicated below. The CWF shall continue
to include or exclude all other claim types in accordance with the logic and processes that
it had in place prior to that release.
D. New A/B MAC (B) Inclusion or Exclusion Logic
The CWF shall read the first two (2) positions of the Business Segment Identifier (BSI),
as reported on the HUBC claim, to uniquely include or exclude claims from state-specific
A/B MACs (B) or DME MACs, as indicated on the COIF.
E. Exclusion of Fully Paid Claims
The CWF shall continue to exclude Part B claims paid at 100 percent by checking for the
presence of claims entry code ‘1’ and determining that each claim’s allowed amount
equals the reimbursement amount and confirming that the claim contains no denied
services or service lines.
The CWF shall continue to read action code ‘1’ and determine that there are no
deductible or co-insurance amounts for the purpose of excluding Part A original claims
paid at 100 percent. In addition, CWF shall determine that the Part A claim contained a
reimbursement amount before excluding a claim with action code ‘1’ that contained no
deductible and co-insurance amounts and that the claim contained no denied services or
service lines.
Claims with Fully Paid Lines, without Deductible or Co-insurance Remaining, and
Additional Denied Service Lines
New HUBC Line-Level Indicator Field

Effective January 4, 2010, the CWF maintainer created a new 1-byte liability denial
indicator (LIAB IND) at the service line level for individually denied claim lines in
association with the HUBC claim transaction (valid values=B or spaces).
Part B Shared System Requirements
When the Part B shared system adjudicates claims where most of the claim service detail
lines are fully [or 100 percent] paid (i.e., contain allowed amounts per line that are the
same as the paid amounts per line and the lines do not carry deductible or co-insurance
amounts) but where some detail lines are denied, it shall take the following actions:
1) Input a “B” value in the newly created 1-byte LIAB IND field for each denied
service line where the beneficiary has payment liability (NOTE: there may be
multiple instances where the “B” value will be applied, contingent upon whether
the beneficiary is liable for each of the denied service lines);
2) Input spaces in the newly created 1-byte LIAB IND field for each denied service
line where the provider, rather than the beneficiary, is contractually liable for the
denied service; and
3) Transmit the HUBC claim to CWF for normal verification and validation
processing.
CWF Requirements
The CWF system shall modify its logic for “original” fully paid claims, without
deductible or co-insurance remaining, in association with Part B HUBC claims as
follows:
1) 	Continue to verify the claim’s entry or action code for confirmation that the
claim is an original;
2) 	Confirm that the claim contains service lines where the amount allowed per line
equals the amount paid per line;
3) 	Check for the presence of a “B” line LIAB IND in association with any of the
denied service lines on the claim;
4) 	Suppress the claim from the crossover process if the claim does not contain a
“B” line LIAB IND for any of the denied service lines; and
5) 	Select the claim for crossover if even one of the denied lines contains a “B” line
LIAB IND.
Upon suppressing the Part B claim from the crossover process, CWF shall annotate the
claim on the Part B claim detail (PTBH) screen with a newly created “AF” (Fully
reimbursable claim containing denied lines with no beneficiary liability) claims crossover

disposition indicator. (See § 80.5 of this chapter for more details regarding crossover
disposition indicators.)
F. Claims Paid at Greater than 100 Percent of the Submitted Charge
The CWF shall modify its current logic for excluding Part A original Medicare claims
paid at greater than 100 percent of the submitted charges as follows:
In addition to meeting the CWF exclusion criteria for Part A claims paid at greater than
100 percent of the submitted charges, CWF shall exclude these claims only when there is
no deductible or co-insurance amounts remaining on the claims.
NOTE: The current CWF logic for excluding Part B original Medicare claims paid at
greater than 100 percent of the submitted charges/allowed amount (specifically, type F
ambulatory surgical center claims, which typically carry deductible and co-insurance
amounts) shall remain unchanged.
G. Claims with Monetary or Non-Monetary Changes
The CWF shall check the reimbursement amount as well as the deductible and co-
insurance amounts on each claim to determine whether a monetary adjustment change to
an original Part A, B, or DMEPOS claim occurred.
To exclude non-monetary adjustments for Part A, B, and DMEPOS claims, the CWF
shall check the reimbursement amount as well as the deductible and co-insurance
amounts on each claim to confirm that there were no monetary changes on the adjustment
claim as compared to the original claim.
Effective with April 1, 2008, the CWF shall also include total submitted/billed charges as
part of the foregoing elements used to exclude adjustment claims, monetary as well as
adjustment claims, non-monetary. (See sub-section N, “Overarching Adjustment Claim
Exclusion Logic,” for details concerning the processes that CWF shall follow when the
COBA trading partner’s COIF specifies exclusion of all adjustment claims.)
H. Excluding Adjustment Claims When the Original Claim Was Also Excluded
When the CWF processes an adjustment claim, it shall take the following action when the
COIF indicates that the “production” COBA trading partner wishes to receive adjustment
claims, monetary or adjustment claims, non-monetary:
• 	Return a BOI reply trailer 29 to the A/B MAC or DME MAC if CWF locates the
original claim that was marked with an ‘A’ crossover disposition indicator or if
the original claim’s crossover disposition indicator was blank/non-existent;
• 	Exclude the adjustment claim if CWF locates the original claim and it was
marked with a crossover disposition indicator other than ‘A,’ meaning that the
original claim was excluded from the COBA crossover process.

CWF shall not be required to search archived or purged claims history to determine
whether an original claim had been crossed over.
The CWF maintainer shall create a new ‘R’ crossover disposition indicator, as referenced
in a chart within §80.5 of this chapter, to address this exclusion for customer service
purposes. The CWF maintainer shall ensure that adjustment claims that were excluded
because the original claim was not crossed over shall be marked with an ‘R’ crossover
disposition indicator after they have been posted to the appropriate HIMR detailed history
screen.
I. Excluding Part A, B, and DME MAC Fully Paid Adjustment Claims Without
Deductible and Co-Insurance Remaining
The CWF shall apply logic to exclude Part A and Part B (including DMEPOS)
adjustment claims (identified as action code ‘3’ for Part A claims and entry code ‘5’ for
Part B and DMEPOS claims) when the COIF indicates that a COBA trading partner
wishes to exclude adjustment claims that are fully paid and without deductible or co-
insurance amounts remaining.
Effective with October 1, 2007, CWF developed logic as follows to exclude fully paid
Part A adjustment claims without deductible and co-insurance remaining:
1) 	Verify that the claim contains action code ‘3’;
2) 	Verify that there are no deductible and co-insurance amounts on the claim;
3) 	Verify that the reimbursement on the claim is greater than zero; and
4) 	Confirm that the claim contains no denied services or service lines.
Special Note: Effective with October 1, 2007, CWF ceased by-passing the logic to
exclude Part A adjustments claims fully (100 percent) paid in association with home
health prospective payment system (HHPPS) types of bills 329 and 339. The CWF shall
exclude such claims if the COIF designates that the trading partner wishes to exclude
“adjustment claims fully paid without deductible or co-insurance remaining” or if these
bill types are otherwise excluded on the COIF.
The CWF shall develop logic as follows to exclude Part B or DMEPOS fully paid
adjustment claims without deductible or co-insurance remaining:
1) 	Verify that the claim contains an entry code ‘5’;
2) 	Verify that the allowed amount equals the reimbursement amount; and
3) 	Confirm that the claim contains no denied services or service lines.
The CWF maintainer shall create a new ‘S’ crossover disposition indicator for adjustment
claims that are paid at 100 percent. The CWF maintainer shall ensure that excluded
adjustment claims that are paid at 100 percent shall be marked with an ‘S’ crossover
disposition indicator after they have been posted to the appropriate HIMR detailed history
screen. In addition, the CWF maintainer shall add “Adj. Claims-100 percent PD” to the

COBA Insurance File Summary screen (COBS) on HIMR so that this exclusion will be
appropriately displayed for customer service purposes.
Claims with Fully Paid Lines, without Deductible or Co-insurance Remaining, and
Additional Denied Service Lines
New HUBC Line-Level Indicator Field
Effective January 4, 2010, the CWF maintainer created a new 1-byte LIAB IND at the
service line level for individually denied claim lines in association with the HUBC claim
transaction (valid values=B or spaces).
Part B Shared System Requirements
When the Part B shared system adjudicates adjustment claims where most of the claim
service detail lines are fully [or 100 percent] paid (i.e., contain allowed amounts per line
that are the same as the paid amounts per line and the lines do not carry deductible or co-
insurance amounts) but where some detail lines are denied, it shall take the following
actions:
1) 	Input a “B” value in the newly created 1-byte LIAB IND field for each denied
service line where the beneficiary has payment liability (NOTE: there may be
multiple instances where the “B” value will be applied, contingent upon
whether the beneficiary is liable for each of the denied service lines);
2) 	Input spaces in the newly created 1-byte LIAB IND field for each denied
service line where the provider, rather than the beneficiary, is contractually
liable for the denied service; and
3) 	Transmit the HUBC claim to CWF for normal verification and validation
processing.
CWF Requirements
The CWF system shall modify its logic for “adjustment” fully paid claims, without
deductible or co-insurance remaining, in association with Part B HUBC claims as
follows:
1) 	Continue to verify the claim’s entry or action code for confirmation that the claim
is an adjustment;
2) 	Where applicable, also continue to check additionally to determine if the
incoming claim contains entry code 5 or an “R” recovery audit contractor (RAC)
adjustment indicator, as directed in previous CMS instructions;
3) 	Where applicable, continue to check additionally to determine if the incoming
claim contains an entry or action code value of “1,” along with Claim Adjustment
Indicator=A, as per previous CMS direction;

4) 	Confirm that the claim contains service lines where the amount allowed per line
equals the amount paid per line;
5) 	Check for the presence of a “B” line LIAB IND in association with any of the
denied service lines on the claim;
6) 	Suppress the claim from the crossover process if the claim does not contain a “B”
line LIAB IND for any of the denied service lines; and
7) 	Select the claim for crossover if even one of the denied lines contains a “B” LIAB
IND.
Upon suppressing the Part B claim from the crossover process, CWF shall annotate the
claim on the Part B claim detail (PTBH) screen with a newly created “AF” (Fully
reimbursable claim containing denied lines with no beneficiary liability) claims crossover
disposition indicator. (See § 80.5 of this chapter for more details regarding crossover
disposition indicators.)
J. Excluding Part A, B, and DME MAC Adjustment Claims That Are Fully Denied
with No Additional Liability
The CWF shall apply logic to exclude Part A and Part B (including DMEPOS) fully
denied adjustment claims that carry no additional beneficiary liability when the COIF
indicates that a COBA trading partner wishes to exclude such claims.
Effective with October 1, 2007, the CWF shall apply logic to the Part A adjustment claim
(action code ‘3’) where the entire claim is denied and the beneficiary has no additional
liability. As of January 4, 2010, that logic was changed to also include the reading of
action code 8, in addition to action code 3, for HUIP and HUOP claims. The revised
logic will thus be as follows:
1) Verify that the claim was sent as action code ‘3’;
2) Verify also if an HUIP or HUOP claim contains action code ‘8’ rather than
an action code ‘3’; and
3) Check for the presence of an ‘N’ beneficiary liability indicator in the
header of the fully denied claim. (See the “Beneficiary Liability Indicators on
Part A CWF Claims Transactions” section above for additional information.)
The CWF shall apply logic to the Part B and DMEPOS adjustment claims (entry code
‘5’) where the entire claim is denied and the beneficiary has no additional liability as
follows:
1) 	Verify that the claim was sent as entry code ‘5’; and
2) 	Check for the presence of an ‘N’ liability indicator on the fully denied claim.

The CWF maintainer shall create a new ‘T’ crossover disposition indicator for adjustment
claims that are 100 percent denied with no additional beneficiary liability. The CWF
maintainer shall ensure that excluded adjustment claims that were entirely denied and
contained no beneficiary liability shall be marked with a ‘T’ crossover disposition
indicator after they have been posted to the appropriate HIMR detailed history screen. In
addition, the CWF maintainer shall add “Denied Adjs-No Liab” to the COBS on HIMR
so that this exclusion will be appropriately displayed for customer service purposes.
K. Excluding Part A, B, and DME MAC Adjustment Claims That Are Fully Denied
with No Additional Liability
The CWF shall apply logic to exclude Part A and Part B (including DMEPOS) fully
denied adjustment claims that carry additional beneficiary liability when the COIF
indicates that a COBA trading partner wishes to exclude such claims.
Effective with October 1, 2007, the CWF shall apply logic to the Part A adjustment claim
(action code ‘3’) where the entire claim is denied and the beneficiary has additional
liability. As of January 4, 2010, that logic shall be changed to also include the reading of
action code 8, in addition to action code 3, for HUIP and HUOP claims. The revised
logic will thus be as follows:
1) 	Verify that the claim was sent as action code ‘3’;
2) 	Verify also if an HUIP or HUOP claim contains action code ‘8’ rather than an
action code ‘3’; and
3) 	Check for the presence of an ‘L’ beneficiary liability indicator in the header of the
fully denied claim. (See the “Beneficiary Liability Indicators on Part A CWF
Claims Transactions” section above for additional information.)
The CWF shall apply logic to exclude Part B and DMEPOS adjustment claims (entry
code ‘5’) where the entire claim is denied and the beneficiary has additional liability as
follows:
1) 	Verify that the claim was sent as entry code ‘5’; and
2) 	Check for the presence of an ‘L’ liability indicator on the fully denied claim.
The CWF maintainer shall create a new ‘U’ crossover disposition indicator for
adjustment claims that are 100 percent denied with additional beneficiary liability. The
CWF maintainer shall ensure that excluded adjustment claims that were entirely denied
and contained beneficiary liability shall be marked with a ‘U’ crossover disposition
indicator after they have been posted to the appropriate HIMR detailed history screen. In
addition, the CWF maintainer shall add “Denied Adjs-Liab” to the COBS on HIMR so
that this exclusion will be appropriately displayed for customer service purposes.
L. Excluding MSP Cost-Avoided Claims

The CWF shall develop logic to exclude MSP cost-avoided claims when the COIF
indicates that a COBA trading partner wishes to exclude such claims.
The CWF shall apply the following logic to exclude Part A MSP cost-avoided claims:
• 	Verify that the claim contains one of the following MSP non-pay codes:
E, F, G, H, J, K, Q, R, T, U, V, W, X, Y, Z, 00, 12, 13, 14, 15, 16, 17, 18,
25, and 26.
The CWF shall apply the following logic to exclude Part B and DMAC MSP cost-
avoided claims:
• 	Verify that the claim contains one of the following MSP non-pay codes:
E, F, G, H, J, K, Q, R, T, U, V, W, X, Y, Z, 00, 12, 13, 14, 15, 16, 17, 18,
25, and 26.
The CWF maintainer shall create a new ‘V’ crossover disposition indicator for the
exclusion of MSP cost-avoided claims. The CWF maintainer shall ensure that excluded
MSP cost-avoided claims shall be marked with a ‘V’ crossover disposition indicator after
they have been posted to the appropriate HIMR detailed history screen. In addition, the
CWF maintainer shall add “MSP Cost-Avoids” to the COBS on HIMR so that this
exclusion will be appropriately displayed for customer service purposes.
M. Excluding Sanctioned Provider Claims from the COBA Crossover Process
Effective with April 2, 2007, the CWF maintainer created space within the HUBC claim
transaction for a newly developed ‘S’ indicator, which designates ‘sanctioned provider.’
A/B MACs (B) that process claims from physicians (e.g., practitioners and specialists) and
suppliers (independent laboratories and ambulance companies) shall set an ‘S’ indicator
in the header of a fully denied claim if the physician or supplier that is billing is
suspended/sanctioned. NOTE: Such physicians or suppliers will have been identified by
the Office of the Inspector General (OIG) and will have had their Medicare billing
privileges suspended. Before setting the ‘S’ indicator in the header of a claim, the A/B
MAC (B) shall first split the claim it is contains service dates during which the provider is
no longer sanctioned. This will ensure that the A/B MAC (B) properly sets the ‘S’
indicator for only those portions of the claim during which the provider is sanctioned.
Upon receipt of an HUBC claim that contains an ‘S’ indicator, the CWF shall exclude the
claim from the COBA crossover process. The CWF therefore shall not return a BOI
reply trailer 29 to the A/B MAC (B) for any HUBC claim that contains an ‘S’ indicator.
N. Overarching Adjustment Claim Exclusion Logic
“Overarching adjustment claim logic” is defined as the logic that CWF will employ,
independent of a specific review of claim monetary changes, when a COBA trading
partner’s COIF specifies that it wishes to exclude all adjustment claims.

Modified CWF Logic
Effective with April 1, 2008, the CWF maintainer shall change its systematic logic to
accept a new version of the COIF that now features a new “all adjustment claims”
exclusion option.
For the COBA eligibility file-based crossover process, where CWF utilizes both the BOI
auxiliary record and the COIF when determining whether it should include or exclude a
claim for crossover, CWF shall apply the overarching adjustment claim logic as follows:
• 	Verify that the incoming claim has an action code of 3 or entry code of 5 or, if
the claim has an action or entry code of 1 (original claim), confirm whether it
has an “A” claim header value, which designates adjustment claim for
crossover purposes; and
• 	Verify that the COIF contains a marked exclusion for “all adjustment claims.”
If these conditions are met, CWF shall exclude the claim for crossover under
the COBA eligibility file-based crossover process.
If both of these conditions are met, CWF shall exclude the claim for crossover under the
COBA eligibility file-based crossover process. IMPORTANT: Independent of the
foregoing requirements, CWF shall continue to only select an adjustment claim for
COBA crossover purposes if: 1) it locates the matching original claim; and 2) it
determines that the original claim was selected for crossover (see “H. Excluding
Adjustment Claims When the Original Claim Was Also Excluded” above for more
information).
New Crossover Disposition Indicator
Upon excluding the claim, CWF shall mark the claim as it is stored on the appropriate
HIMR claim detail history screen with a newly developed “AC” crossover disposition
indicator, which designates that CWF excluded the claim because the COBA trading
partner wished to exclude all adjustment claims. (See §80.5 of this chapter for a
description of this crossover disposition indicator.)
The CWF shall display the new indicator within the “eligibility file-based crossover”
segment of the HIMR detailed claim history screen.
Exception Concerning COBA IDs in the Medigap Claim-based Range
CWF shall never apply the new overarching adjustment claim exclusion logic to
incoming HUBC or HUDC claims whose field 34 (“Crossover ID”) header value falls
within the range of 0000055000 to 0000059999, which represents the COBA identifier of
a COBA Medigap claim-based crossover recipient, and for which there is not a
corresponding BOI auxiliary record that likewise contains that insurer identifier. (See

§80.7 of this chapter for more information concerning the COBA Medigap claim-based
crossover process.)
O. Exclusion of Claims Containing Placeholder National Provider Identifier (NPI)
Values
Effective October 6, 2008, the CWF maintainer created 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,” which shall designate that CWF auto-excluded the claim because it
contained a placeholder provider value (see §80.5 of this chapter 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 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: 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 screens and on
page 3 of the HIMR A/B MAC (A) claim detail screen.
P. Excluding Physician Quality Reporting System (PQRS) Only Codes Reported on
837 Professional Claims
Effective October 6, 2008, the CWF maintainer shall create space within the header of its
HUBC claim transmission for a 1-byte PQRS 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 PQRS codes (see
§80.5 of this chapter for more details regarding the bypass indicator).

Prior to transmitting the claim to CWF for normal processing, MCS shall input the value
“Q” in the newly defined PQRS 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 PQRS field (which
signifies that the claim contains only PQRS 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 Part B claim detail screen.
Q. CWF Requirements for Health Care Pre-Payment Plans (HCPPs) that Receive
Crossover Claims
Effective January 5, 2009, at CMS’s direction, the BCRC assigned all HCPP COBA
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. (Refer to chapter 28,
§70.6 for MAC requirements in association with HCPP and HMO cost plan crossovers.)
R. Inclusion or Exclusion of Part A Claims By Provider Identification Number (ID)
as well as Provider State
Since July 2004, the CWF has read the incoming BCRC-created COIF to determine each
national COBA trading partner’s specific claims selection as tied to each COBA ID. To
accommodate the inclusion or exclusion of Part A specific provider identifiers (IDs),
CWF currently reads the numeric value reported on the COIF by COBA ID and then
interrogates the “Provider ID,” CMS Certification Number (CCN) reported on the
incoming HUIP, HUOP, HUHH, or HUHC claims transaction. For instances where a
match is found, CWF either includes or excludes the claim from the national crossover
process, in accordance with the “I” or “E” indicator that precedes the provider ID value
reported beginning with field 225 of the COIF.
Also, since July 2004, CWF has read the 2-digit state code as referenced on the COIF as
a basis for including or excluding Part A claims by provider state. In performing this
function, CWF locates the incoming “Provider ID” on the HUIP, HUOP, HUHH, or
HUHC claims transaction and determines if the first 2 bytes match the 2-byte state code
on the BCRC-created COIF. 	If a match is found, CWF either includes or excludes the
claim based upon the “I” or “E” value reported in field 224 of the COIF.
Effective April 4, 2011, upon its receipt of either a 6-byte CMS Certification Number
(CCN) or a 10-digit NPI, as found starting in position 225 of the COIF, CWF shall check
both the “Provider ID” and “NPI” fields of the incoming HUIP, HUOP, HUHH, or
HUHC for potential matches. If CWF finds a provider ID or NPI match, it shall either
include or exclude the claim based upon the indicator (I or E) reported in field 224 of the
COIF.

The CWF shall continue to either 1) include the claim if the “I” indicator precedes the
provider ID or NPI reported on the COIF or 2) exclude the claim and annotate Part A
claims history with crossover indicator “K” when the reported provider ID or NPI on the
COIF is identified for exclusion from the crossover process. (See §80.5 of this chapter for
more information concerning the “K” crossover disposition indicator.)
S. Excluding Fully Denied Claims Adjudicated With An “Other Adjustment”
(OA”) Claim Adjustment Segment Group Code
Effective October 4, 2010, the CWF maintainer created space within the header of its
HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claims transactions for a 1-byte
Claim Adjustment Segment (CAS) Group Code Indicator field (valid values=G or space).
In addition, CWF developed a new 2-byte “BG” COBA By-pass indicator, which
designates that CWF auto-excluded the claim because it was adjudicated with an “OA”
CAS group code for all denied lines or services.
Prior to transmitting their adjudicated claims to CWF for normal processing, all shared
systems shall input the value “G” in the newly defined 1-byte CAS Group Code Indicator
field in the header of their HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claims when
all services or claim detail service lines on the affected claims are denied with Group
Code “OA.”
Upon receipt of a claim that contains a “G” in the newly defined CAS Group Code
Indicator field, CWF shall auto-exclude the claim from the national COBA eligibility
file-based and Medigap claim-based crossover processes. (NOTE: CWF shall not be
required to read the COIF to determine COBA trading partner preferences for claims
containing either an “L” or “N” beneficiary liability indicator when the incoming claim
contains a “G” in the newly defined CAS Group Code Indicator field.)
Following auto-exclusion of the claim, CWF shall take the following actions:
1) Annotate the claim with a “BG” COBA bypass indicator; and
2) Display the “BG” indicator as part of the COBA Bypass segment on page 3 of the
appropriate HIMR claim detail screen.
Effective with October 3, 2011, CWF created a consistency edit that will activate when
the shared systems send HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims to
CWF that contain a value in the CAS Group Code Indicator field other than G or spaces.
Upon receipt of this consistency edit, the shared system shall take the following actions:
1) 	Modify the value reported in the CAS Group Code Indicator either to a “G,”
if appropriate, or spaces; and
2) 	Retransmit the claim to CWF.

T. 	New Requirements for Other Federal Payers
Effective with October 3, 2011, the CWF maintainer expanded 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 this chapter for additional information concerning this indicator.)
U. CWF and Shared Systems Handling of Claims Where Principal Diagnosis Is “E”
Code or Equivalent Code in Successive ICD Diagnosis Versions
Effective April 1, 2013, CWF created a new 1-byte “First Reported DX Code Indicator”
field within the header of incoming HUBC and HUDC claims transactions. CWF shall
only accept “Y” or spaces as valid values for the newly created First Reported DX Code
Indicator within the header of incoming HUBC and HUDC claims and shall develop
consistency edits to address invalid values submitted in the newly created field.

For applicable situations where claims having a principle (first-listed) “E” ICD-9 code or,
when ICD-10 diagnosis coding is implemented, equivalent V00--Y99 ICD-10 diagnosis
code are either not rejected due to front-end editing or are returned as unprocessable, the
Part B and DME MAC shared systems shall:
• 	Input a “Y” indicator in the First Reported DX Code field (header) of the HUBC
and HUDC claims; and
• 	Transmit the affected claims to CWF for normal processing.
The shared systems shall have the ability to react to CWF consistency edits received
when invalid values are entered in the newly created DX Code Indicator field.
Upon receipt of claims that contain a “Y” in First Reported DX Code Indicator field,
CWF shall by-pass the claims from crossing over. CWF shall create a new “BX” COBA
by-pass indicator that it will apply to claims where a “Y” is present within the DX Code
Indicator field (See §80.5 of this chapter for more information regarding the new
indicator). Additionally, CWF shall display the new by-pass indicator on the appropriate
page(s) of the HIMR claims detail screens.
80.5 - Claims Crossover Disposition and Coordination of Benefits
Agreement Bypass Indicators
(Rev. 4474, Issued; 12-06-19, Effective: 01-04-20, Implementation: 01-06-20)
1. Claims Crossover Disposition Indicators
Effective with the October 2004 systems release, when a COBA trading partner is in
production mode (Test/Production Indicator sent via the COIF submission=P), CWF shall
annotate each processed claim on detailed history in the HIMR with a claims crossover
disposition indicator after it has applied the COBA trading partner’s claims selection
criteria. (See the table below for a listing of the indicators.) In addition, when a COBA
trading partner is in production mode, CWF shall annotate each processed claim with a
10-position COBA ID (5-digit COBA ID preceded by 5 zeroes) to identify the entity to
which the claim was crossed or not crossed, in accordance with the terms of the COBA.
Effective with October 2006, the CWF maintainer updated its data
elements/documentation to capture the revised descriptor for crossover disposition
indicators “E,” as reflected below. In addition, the CWF maintainer shall update its data
elements/documentation to capture the newly added “R,” “S,” “T,” “U,” and “V”
crossover disposition indicators, as reflected in the Claims Crossover Disposition
Indicators table below.
Effective with July 2007, the CWF maintainer updated its data elements/ documentation
to capture the newly added “W,” “X,” and “Y” crossover disposition indicators, as well
as all other changes, reflected in the table directly below.

As reflected in the table below, the CWF maintainer created crossover disposition
indicators “Z” and “AA” to be effective October 1, 2007. The CWF maintainer created a
new “AC” crossover disposition indicator as part of its COBA claims selection
processing effective April 1, 2008.
Effective January 5, 2009, the CWF maintainer created crossover disposition indicators
“AD” and “AE,” as indicated in the table below. The CWF shall utilize the “AD”
indicator when an incoming claim does not meet any of the new adjustment, mass
adjustment, or recovery audit contractor (RAC)-initiated adjustment inclusion criteria, as
specified in §80.8 of this chapter. The CWF shall utilize the “AE” indicator when the
COBA trading partner specifies that it wishes to exclude RAC-initiated adjustments and
CWF does not otherwise exclude the claim for some other reason identified higher within
its crossover exclusion logic hierarchy.
Effective with the July 2009 release, the CWF maintainer shall display all auto-
exclude/COBA by-pass events, as detailed below, in association with an adjudicated
claim within the COBA bypass field on page 3 of the HIMR intermediary claim detail
screen and on page 2 of the HIMR Part B and DMEL detail screen.
The CWF shall, in addition, create and display a new “BT” crossover disposition
exclusion indicator on pages 2 and 3 of the HIMR claim detail screens, as appropriate,
effective with July 2009.
Additionally, the CWF maintainer shall create additional fields within claim page 3 of the
HIMR intermediary claim detail screen and page 2 of the Part B and DMEL claim detail
screens to allow for the reporting of crossover disposition indicators in association with
“test” COBA crossover claims. The CWF maintainer shall 1) create additional fields for
displaying “test” crossover disposition indicators within both the eligibility file-based and
claim-based crossover portions of the claim detail screens on HIMR; and 2) display the
“test” crossover disposition indicators so that they mirror all such indicators used for
“production” claims in association with the following four (4) claim versions: 4010A1,
5010, National Council for Prescription Drug Programs (NCPDP)-5.1, and NCPDP-D.0.
IMPORTANT: If the BCRC transmits a COIF that contains a COBA ID within the
range 79000 through 79999 (Medicaid quality project), CWF shall post an “MQ”
disposition indicator in association with the claim instead of the traditional “A” indicator
when it selects the claim for crossover. (NOTE: “MQ” shall designate that Medicare is
transferring the claim for Medicaid quality project purposes only.) CWF shall annotate
claims whose COBA ID is 79000 through 79999 with “MQ” regardless of the claim
version indicator in those instances where it selects the claims for crossover to the BCRC.
CWF shall also annotate the claims with MQ if the COBA ID is marked on the COIF as
being in test (T) or production (P) mode. If CWF excludes from crossover a claim where
the COBA ID equals 79000 through 79999, CWF shall continue to post the crossover
disposition indicator that corresponds to the reason for the exclusion on the appropriate
HIMR claim detail screen.

Effective January 4, 2010, CWF shall apply the newly developed crossover disposition
indicator “AF” (see below) to incoming Part B original and adjustment fully paid claims,
without deductible and co-insurance, when those claims contain denied service lines
where the beneficiary has no liability.
Effective April 6, 2020, CWF shall apply the newly developed crossover disposition
indicator “AG” (see below) to incoming Part B claims that do not meet the Part B
psychotherapy claims inclusion criteria. In addition, CWF shall apply the newly
developed crossover disposition indicator “AH” (see below) to incoming Part B claims
that meet a COBA trading partner’s Part B psychotherapy claims exclusion criteria.
Claims Crossover
Disposition
Indicator
Definition/Description
A 	This claim was selected to be crossed over.
B 	This Type of Bill (TOB) excluded.
C 	Non-assigned claim excluded.
D 	Original Fully Paid Medicare claims without
deductible and co-insurance remaining excluded.
E 	Original Medicare claims paid at greater than 100%
of the submitted charges without deductible or co-
insurance remaining excluded (Part A).
**Also covers the exclusion of Original Medicare
claims paid at greater than 100% of the submitted
charges excluded for Part B ambulatory surgical
center (ASC) claims, even if deductible or co-
insurance applies.
F 	100% denied claims, with no additional beneficiary
liability excluded.
G 	100% denied claims, with additional beneficiary
liability excluded.
H 	Adjustment claims, monetary, excluded (not
representative of mass adjustments).
I 	Adjustment claims, non-monetary/statistical,
excluded (not representative of mass adjustments).
J 	MSP claims excluded.
K 	This claim contains a provider identification
number (ID) or provider state that is excluded by
the COBA trading partner.
L 	Claims from this A/B MAC or DME MAC ID
excluded.
M 	The beneficiary has other insurance (such as
Medigap, supplemental, TRICARE, or other) that
pays before Medicaid. Claim excluded by
Medicaid.

N 	NCPDP claims excluded.
O 	All Part A claims excluded.
P 	All Part B claims excluded.
Q 	All DME MAC claims excluded.
R 	Adjustment claim excluded because original claim
was not crossed over.
S 	Adjustment fully paid claims with no deductible or
co-Insurance remaining excluded.
T 	Adjustment Claims, 100% Denied, with no
additional beneficiary liability excluded.
U 	Adjustment Claims, 100% Denied, with additional
beneficiary liability excluded.
V 	MSP cost-avoided claims excluded.
W 	Mass Adjustment Claims—Medicare Physician Fee
Schedule (MPFS) excluded.
X 	Mass Adjustment Claims—Other excluded.
Y 	Archived adjustment claim excluded.
Z 	Invalid Claim-based Medigap crossover ID
included on the claim.
AA 	Beneficiary identified on Medigap insurer
eligibility file; duplicate Medigap claim-based
crossover voided
AB 	Not Used; already utilized in another current CWF
application or process.
AC 	All adjustment claims excluded.
AD 	Adjustment inclusion criteria not met.
AE 	Recovery audit A/B MAC or DME MAC (RAC)-
initiated adjustment excluded.
BT 	Individual COBA ID did not have a matching
COIF.
MQ 	Claim transferred for Medicaid quality project
purposes only.
AF 	Fully reimbursable claim containing denied lines
with no beneficiary liability excluded.
AG 	Part B psychotherapy claims inclusion criteria not
met.
AH 	Part B psychotherapy claims excluded.
AV 	Void/cancel claim suppressed because the original
claim was excluded
2. COBA Bypass Indicators
Effective with the October 2008 release, the CWF maintainer shall display COBA bypass
indicators in association with claims posted on HIMR. These indicators will appear on
page 2 of the PTBH and DMEH screens and on page 3 of the INPH, OUTH, HHAH, or
HOSH screens. The COBA Bypass Indicators appear in the table directly below.

Effective with the July 2009 release, the CWF maintainer shall additionally display
bypass indicators BA, BB, BC, BD, BE, BF, BP, and BR on the appropriate detailed
screens (PTBH or DMEH; INPH, OUTH, HHAH, or HOSH) on HIMR.
Effective with the October 2010 release, the CWF maintainer shall display the new “BG”
COBA bypass indicator on the appropriate claim detail screens (PTBH, DMEH, INPH,
OUTH, HHAH, or HOSH) on HIMR.
Effective April 1, 2013, the CWF maintainer shall display the new “BX” COBA bypass
indicator on the appropriate claim detail screens (PTBH, DMEH, INPH, OUTH, HHAH,
or HOSH) on HIMR.
Effective July 1, 2019, the CWF maintainer shall display the new “BY” COBA bypass
indicator on the appropriate claim detail screens (PTBH, DMEH, INPH, OUTH, HHAH,
or HOSH) on HIMR.
Claims Crossover
Bypass Indicator
Definition/Description
BA 	Claim represents an “Add History” only (action
code 7 on HUOP claims; entry code 9 on HUBC
and HUDC claims). Therefore, the claim is
bypassed and not crossed over.
BB 	Claim falls into one of two situations: 1) there is no
eligibility record (exception: if HUBC or HUDC
claim has a Medigap claim-based COBA ID); or 2)
the only available eligibility record contains a “Y”
delete indicator. Therefore, the claim is bypassed
and not crossed over.
BC 	Claim represents an abbreviated encounter record
(TOB=11z; condition code=04 or 69); therefore,
the claim is bypassed and not crossed over.
BD 	Claim contains a Part B/DME MAC CWF claim
disposition code other than 01, 03, or 05; therefore,
the claim is bypassed and not crossed over.
BE 	Submission of Notice of Elections [NOEs]
(Hospice—TOB= 8xA through 8xE on HUHC;
CEPP—TOB=11A through 11D on HUIP;
Religious Non-Medical Care—TOB=41A, 41B,
and 41D on HUIP; Medicare Coordinated Care –
TOB=89A and 89B on HUOP). Therefore, the
submission is bypassed and not crossed over.
BF 	Claim represents an excluded demonstration
(DEMO) project; therefore, the claim is bypassed
and not crossed over.

Claims Crossover
Bypass Indicator
Definition/Description
BG 	CWF auto-excluded the claim because it was
adjudicated with an “OA” Claim Adjustment
Segment (CAS) Group code for all denied lines or
services.
BN 	CWF auto-excluded the claim because it contained
a placeholder provider value.
BP 	Sanctioned provider claim during service dates
indicated; therefore, the claim is bypassed and not
crossed over.
BQ 	CWF auto-excluded the claim because it contained
only PQRS codes.
BR 	Submission for Request for Anticipated Payment
[RAP] claims (TOB=322 and 332); therefore, the
submission is bypassed and not crossed over.
BX 	Non-compliant ICD DX code on claim; therefore,
the claim is by-passed and not crossed over.
BY 	A BOI record exists, but there are no active BOI
entries that correspond to the claim's service dates.
Therefore, the claim is bypassed and not crossed
over.
80.6 - Special Mass Adjustment and Other Adjustment Crossover
Requirements
(Rev. 13314; Issued: 07-24-25; Effective: 01-01-26; Implementation: 01-05-26)
1. Developing a Capability to Exclude Mass Adjustment Claims Tied to the Medicare
Physician Fee Schedule Updates and Mass Adjustment Claims-Other
Effective with July 2, 2007, the CWF maintainer created a new header field for a one (1)-
byte mass adjustment indicator within its HUBC, HUDC, HUOP, HUHH, and HUHC
claims transactions. The valid values for the newly created field shall be ‘M’—mass
adjustment claim-Medicare Physician Fee Schedule (MPFS) and ‘O’—mass adjustment
claim-other. Further, effective with that date, the BCRC shall send the CWF host sites a
modified COIF that contains two new claims exclusion categories: mass adjustments-
MPFS and mass adjustments-other.
Effective January 5, 2026, the CWF maintainer shall accept the new one (1)-byte Mass
Adjustment Indicator value of “N” (defined as Affordable Care Act (ACA) mass

adjustment) within the header of its HUIP, HUOP, HUHH, and HUHC claims
transactions. Additionally, the CWF maintainer shall modify Part A consistency edit 0045
to accept the new Mass Adjustment indicator value of "N." Thus, effective January 5, 2026,
the valid values for the Mass Adjustment Indicator field will include N, as well as M and
O.
Upon receipt of a claim that contains an “N” or “O” indicator in the header of an HUIP,
HUOP, HUHH, and HUHC claim, CWF shall read the COIF to determine if the COBA
trading partner wishes to exclude “mass adjustment claim--other.” If CWF determines
that the trading partner wishes to exclude the mass adjustment claim--other, it shall
exclude the claim from the COBA crossover process.
Upon receipt of a claim that contains an ‘M’ indicator (new field) in the header of an
HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC claim, CWF shall read the COIF to
determine whether the COBA trading partner wishes to exclude the claim. If CWF
determines that the trading partner wishes to exclude the mass adjustment-MPFS claim, it
shall exclude the claim from the COBA crossover process.
Upon receipt of a claim that contains an ‘O’ indicator in the header of an HUBC, HUDC,
HUIP, HUOP, HUHH, or HUHC claim, which designates ‘mass adjustment claim-other,’
the CWF shall read the COIF to determine whether the COBA trading partner wishes to
exclude the claim. If CWF determines that the trading partner wishes to exclude mass
adjustment claims-other, it shall exclude the claim from the COBA crossover process.
Creation of New Crossover Disposition Indicators
In relation to its receipt of a claim that has either an ‘M’ or an ‘O’ header value, the CWF
shall create two new crossover disposition indicators ‘W’ (“mass adjustment claim-MPFS)
and ‘X’ (“mass adjustments claim-other excluded”) on the HIMR detailed history screens
in association with excluded processed claims for ‘production’ COBA trading partner.
Effective January 5, 2026, CWF shall associate Mass Adjustment Indicator value “N” with
COBA crossover disposition indicator ‘X.”
The CWF shall display each of the new crossover disposition indicators appropriately in
association with the processed mass adjustment claim-MPFS on the HIMR detailed history
screen. (See §80.5 of this chapter for further information.) In addition, the CWF
maintainer shall develop and display two (2) new exclusion fields within the COBA
Inquiry Screen (COBS) for ‘mass adj.-M’ (mass adjustments-MPFS) and ‘mass adj.-O’
(mass adjustments-other).
2. Developing a Capability to Treat Entry Code ‘5’ and Action Code ‘3’ Claims As
Recycled ‘Original’ Claims For Crossover Purposes
Effective July 2007, the CWF maintainer shall create a new header field within its
HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims transactions for a 1-byte -
adjustment indicator (valid values= ‘N’--non adjustment claim for crossover purposes;
‘A’--adjustment claim for crossover purposes; or spaces).

In instances when CWF returns an error code 5600 to an A/B MAC or DME MAC,
thereby causing it to reset the claim’s entry code to ‘5’ to action code to ‘3,’ the A/B
MAC or DME 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, HUIP, HUOP, HUHH, and HUHC claim in the newly defined
field before retransmitting the claim to CWF. The A/B MAC or DME MAC’s 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.
Additional A/B MAC or DME MAC Requirements Following Receipt of a CWF
Beneficiary Other Insurance (BOI) Reply Trailer 29 for Such Claims
Upon receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) for the recycled
claim, the A/B MAC or DME MACs’ systems shall ensure that, as part of their 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 shared systems shall ensure
that, as part of their 837 flat file creation process, they do not create a corresponding 2330
loop REF*T4*Y segment, which typically signifies ‘adjustment.’
3. Developing a Capability to Treat Claims with Non-Adjustment Entry or Action
Codes as Adjustment Claims For Crossover Purposes
In instances where A/B MACs and DME MACs must send adjustment claims to CWF as
entry code ‘1’ or action code ‘1’ (situations where the accrete claim cannot be processed
at CWF), they shall set an ‘A’ indicator in a newly defined field within the header of the
HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC claim.
Upon receipt of a claim that contains entry code ‘1’ or action code ‘1’ with a claim
adjustment indicator 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 or adjustments, non-monetary, or both; and
• 	Suppress the claim from crossover if the COBA trading partner wishes to
exclude either adjustments, monetary or 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.)
By Passing of Logic to Exclude Adjustment Claim if Original Claim was Not
Crossed Over

For purposes of excluding entry code ‘1’ or action code ‘1’ claims that contain an ‘A’
adjustment indicator value, CWF shall 1) assume that the ‘original’ claim that was purged
from its online history was crossed over, and 2) bypass its logic for crossover disposition
indicator ‘R’ (cross the adjustment claim over only if the original claim was previously
crossed over). Refer to §80.4 of this chapter for further details regarding this logic.
Actions to Take When A/B MAC or DME MACs Send Invalid Values
If A/B MAC or DME MAC sends claim adjustment indicator values other than ‘N,’ ‘A,’
or space within the newly designated header field within their HUBC, HUDC, HUIP,
HUOP, HUHH, and HUHC claims to CWF, 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 shared
systems shall correct the invalid value and retransmit the claim to CWF for verification
and validation.
Creation of a New Crossover Disposition Indicator For This Scenario
In relation to its receipt of a claim that has an ‘A’ header value, the CWF shall create a new
crossover disposition indicator ‘Y’ (“archived adjustment claim-excluded”) on the HIMR
detailed history screens in association with excluded processed claims for ‘production’
COBA trading partners. The CWF shall display the new ‘Y’ crossover disposition
indicator in association with the processed mass adjustment claim-MPFS on the HIMR
detailed history screen. (See §80.5 of this chapter for further information.)
Additional A/B MAC or DME MAC Requirements Following Receipt of a CWF
Beneficiary Other Insurance (BOI) Reply Trailer 29
If A/B MACs or DME MACs receive a BOI reply trailer (29) on a claim that had an ‘A’
indicator set in its header, the A/B MAC or DME MACs’ systems shall ensure that, as
part of their 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 a given 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.
80.7 - Coordination of Benefits Agreement (COBA) Medigap Claim-
Based Crossover Process
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Effective with claims submitted to Medicare on October 1, 2007, and after, participating
physicians and suppliers will be expected to include a 5 byte COBA identifier (range
55000---55999) on incoming crossover claims for purposes of triggering claim-based
Medigap crossovers. Additionally, effective with October 1, 2007, claim-based Medigap

crossovers will occur exclusively through the BCRC in the Health Insurance Portability
and Accountability Act (HIPAA) American National Standards Institute (ANSI) X12-N
837 professional claim format (current version) and National Council for Prescription Drug
Programs (NCPDP) claim format.
A. Changes to A/B MAC or DME MAC Up-Front Screening Processes for COBA
Claim-based Medigap Crossovers
Effective with claims that the A/B MACs (B) and DME MACs will cable to CWF on
October 1, 2007, their internal processes for screening claims for Medigap claim-based
crossovers shall be modified to accommodate the new Medigap claim-based COBA
crossover process. The affected A/B MACs (B) and DME MACs’ processes for
screening claims for Medigap claim-based crossovers shall now feature a syntactic
editing of the incoming COBA claim-based Medigap ID to ensure that the identifier
begins with a “5” and contains 5 numeric digits. In addition, for incoming 837
professional and NCPDP claims, A/B MACs (B) and DME MACs shall ensure that the
Medigap claim-based COBA ID is entered within the appropriately designated field,
loop, or segment of the incoming Medicare claim.
If the claim fails the syntactic verification, the A/B MAC (B) or MAC shall not copy the
identifier from the incoming claim and populate it within field 34 (“Crossover ID”) of the
HUBC or HUDC claim transaction that is sent to the CWF for verification and validation.
Instead, the A/B MAC (B) or DME MACs shall continue to follow its pre-existing
processes for notifying the provider via the ERA or other remittance advice and the
beneficiary via the MSN that the information reported did not result in the claim being
crossed over. The affected A/B MACs (B) or DME MACs’ screening processes for
Medigap claim-based crossovers shall also continue to include verification that the
provider participates with Medicare and that the beneficiary has assigned benefits to the
provider.
If the provider-populated value for the Medigap claim-based ID passes the A/B MAC (B)
or DME MAC’s syntactic editing process, the affected A/B MAC or DME MACs’
systems shall copy the Medigap claim-based COBA ID value from the incoming claim to
field 34 of the HUBC or HUDC claims transactions that are sent to CWF for verification
and validation. The A/B MACs (B) and DME MACs shall populate the identifier in field
34 right-justified and prefixed with five zeroes.
B. CWF Validation of Values within Field 34 of the HUBC and HUDC
Transactions
Upon receipt of HUBC and HUDC claims that contain a value within field 34
(“Crossover ID”), the CWF shall read the value that is present within the field for
purposes of conducting a validity check. The CWF shall accept the following values as
valid within field 34: a value within the range of 0000055000 to 0000059999, or spaces.
If the A/B MAC (B) or DME MAC has sent an inappropriate value in field 34 of the
HUBC and HUDC claims transaction, CWF shall return an alert code 7704 on the “01”
disposition response via the claim-based alert trailer 21. 	For customer service purposes,

the CWF maintainer shall create a new crossover disposition indicator “Z” to
accommodate the scenario of the A/B MAC (B) or DME MAC sending an incorrect
value within field 34 of the HUBC and HUDC transaction. (See §80.5 of this chapter for
more information regarding this crossover disposition indicator.) At the point that CWF
returns an alert code 7704 to the affected A/B MAC (B) or DME MAC, it shall take the
following actions with respect to the claim:
1. Mark the claim with crossover disposition indicator “Z” (“invalid Medigap claim-
based crossover ID included on the claim”); and
2. 	Display the indicator, together with the invalid COBA ID value from field 34, in
association with the claim on the appropriate HIMR detailed history screen in the “claim-
based crossover” segment.
See Pub.100-04 chapter 28, §70.6.4 for an explanation of A/B MAC or DME MAC
processes following receipt of a CWF alert code 7704 via a 21 trailer.
C. CWF Processing for COBA Claim-based Medigap Crossovers
Following receipt of an HUBC and HUDC claims transaction that contains a valid value
within field 34 (a value within the range of 0000055000 to 0000059999 or spaces), CWF
shall check for the presence of a BOI auxiliary record for the purpose of triggering
eligibility file-based crossovers. CWF shall then read the COIF to determine the claims
selection criteria for any eligibility file-based trading partners (all other COBA IDs) as
well as for the Medigap claim-based insurer (range 0000055000 to 0000059999). If the
HUBC or HUDC claim contains a valid COBA Medigap claim-based ID within field 34
but the valid ID cannot be found on the COIF, the CWF shall post the valid COBA
Medigap claim-based ID without an accompanying crossover disposition indicator in
association with the claim within the “claim-based crossover” segment of the appropriate
HIMR claim detailed history screen.
If the claim meets the COBA trading partner’s selection criteria, as per the COIF, and
none of the other scenarios presented below applies, CWF shall return a Beneficiary
Other Insurance (BOI) reply trailer (29) to the A/B MAC (Part B) or DME MAC for
purposes of having the A/B MAC (B) or DME MAC trigger a crossover to the BCRC.
Duplicate Check
The CWF shall perform a duplicate check to determine if the beneficiary is identified for
crossover to a Medigap eligibility file-based insurer (COBA ID 30000-54999) and to a
Medigap claim-based insurer (COBA ID 0000055000-0000059999). If CWF determines
that the beneficiary is identified for crossover to both a “production” Medigap eligibility
file-based insurer (COBA ID range=30000 to 54999) and a Medigap claim-based
Medigap insurer (COBA ID range=0000055000 to 0000059999), it shall suppress the
BOI reply trailer (29) for the claim-based Medigap insurer (COBA ID range=
0000055000 to 0000059999).
Crossover Disposition Indicator “AA”

Effective with October 1, 2007, the CWF maintainer created a new crossover disposition
indicator “AA” to accommodate the CWF duplicate check, where it has determined that
the beneficiary’s claim is eligible for crossover to both a “production” Medigap eligibility
file-based insurer and a Medigap claim-based crossover insurer. After CWF has
determined that beneficiary has already been identified for Medigap eligibility file-based
crossover, it shall take the following actions with respect to the claim:
1. Mark the associated claim with indicator “AA” (“beneficiary identified on
Medigap insurer eligibility file; duplicate Medigap claim-based crossover voided); and
2. Display this indicator, together with the affected claim-based Medigap COBA
ID, in association with the claim on the appropriate HIMR detailed history screen in the
“claim-based crossover” segment.
D. BOI Reply Trailer (29) Process
If CWF determines that the claim meets the trading partner’s claims selection criteria, it
shall select the claim and return a BOI reply trailer 29 for the claim to the affected A/B
MAC (B) or DME MAC. The CWF shall display the appropriate crossover disposition
indicator for the claim-based crossover claim within the “claim-based crossover” segment
of the HIMR claim detailed history screens. As with the COBA eligibility file-based
crossover process (see §80.4 of this chapter for more details regarding this process),
CWF shall display the COBA ID and accompanying crossover disposition indicator on
claim detailed history screens, with the exception of circumstances where the valid ID
cannot be located on the COIF, as discussed above, or the Medigap claim-based insurer is
in “test” mode with the BCRC. In these situations, only the COBA Medigap claim-based
ID shall be displayed.
Modification of the CWF Sort Routine For Multiple COBA IDs and Accompanying
A/B MAC or DME MAC Actions Following Receipt of the BOI Reply Trailer (29)
In light of the new COBA Medigap claim-based crossover process, the CWF sort routine
for COBA IDs to be returned via the BOI reply 29 trailer shall be modified as follows:
Medigap eligibility file-based (30000-54999), Medigap claim-based (55000-59999),
supplemental (00001-29999), TRICARE for Life (60000-69999), Other insurer (80000-
89999), and Medicaid (70000-79999). (NOTE: This information is also being updated
in §80.4 of this chapter)
Upon receipt of the BOI reply trailer (29), the affected A/B MAC (B) or DME MAC
shall continue to utilize information from this source to populate the beneficiary’s MSN
and provider ERA or other remittance advice in production in accordance with the
existing guidance that appears in §80.4 of this chapter.
80.8 - Inclusion and Exclusion of Specified Categories of Adjustment
Claims for Coordination of Benefits Agreement (COBA) Crossover
Purposes

(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
1. 	CWF Inclusion of Adjustment Claims
Effective January 5, 2009, the CWF system shall 1) create the newly defined inclusion of
adjustment claims option, along with 1-byte file displacement, within its version of the
COIF; and 2) accept and process this new field when the BCRC transmits it as part of its
regular COIF updates.
Upon receipt of a COIF that features a COBA identification number (ID) with
specifications to include adjustment claims only, the CWF shall select only those claims
for COBA crossover that meet the following specifications:
1) 	The claim’s action code=3, entry code=5, or claim adjustment indicator=“A”—
all of which designate an “adjustment” claim; and
2) 	The claim meets no other exclusion criteria, as specified on the COIF, or does
not meet the NPI placeholder value by-pass exclusion logic.
With the implementation of this change, the CWF shall continue to select adjustment
claims only if it previously selected the “original” claim for crossover (logic for
adjustment indicator “R”; see §80.4 of this chapter for additional details regarding this
logic).
If the incoming HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim contains spaces
in the new designated RAC adjustment indicator field, CWF shall select the claim in
accordance with the COBA trading partner’s claims selection criteria specified on the
COIF.
2. CWF Inclusion of Two Categories of Mass Adjustment Claims for Crossover
Purposes
Effective January 5, 2009, the CWF system shall 1) create the newly defined inclusion of
mass adjustment claims—MPFS updates and mass adjustment claims—other options,
along with accompanying 1-byte file displacement indicators, 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,
CWF shall take the following actions: 1) Verify that the claim transaction contains an “M”
or “O” mass adjustment claim header indicator; 2) verify that the claim’s action code=3, or
entry code=5, or adjustment header indicator=A; 3) check the COIF to determine if the
COBA trading partner wishes to include mass adjustment claims—MPFS or mass
adjustment claims--other; 4) include the claim for crossover, unless the “original” claim
was not crossed over (logic for crossover disposition indicator “R”) or the claim meets any
claims exclusion criteria as specified on the COIF.

If the incoming HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim contains spaces in
the mass adjustment indicator field, CWF shall select the claim per the COBA trading
partner’s claims selection criteria, as specified on the COIF.
3. CWF Inclusion and Exclusion of Recovery Audit A/B MAC or DME MAC (RAC)-
Initiated Adjustment Claims
At CMS’s direction, the BCRC has modified the COIF to allow for the unique inclusion
and exclusion of RAC-initiated adjustment claims. The CWF system shall 1) create the
newly defined inclusion and exclusion of RAC-initiated adjustment options, along with
accompanying 1-byte file displacement, on 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.
Effective January 5, 2009, the CWF maintainer created 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.)
The CWF maintainer shall, in addition, include the 1-byte RAC adjustment indicator in
the header of the claim that is posted to history on HIMR, thereby ensuring that CWF
displays the indicator when a user accesses the INPH, OUTH, PTBH, DMEH, and related
HIMR screens.
Shared System Actions
All 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.
Prior to sending its processed 11X and 12X type of bill RAC adjustment transactions to
CWF for normal verification and validation, the Part A shared system shall input an “R”
indicator in the newly defined header field of its HUIP claims transactions if the RAC-
initiated adjustment claim meets either of the following conditions:
1) The claim recovery action resulted in Medicare changing its payment decision
from paid to denied (i.e., Medicare paid $0.00 as the result of the adjustment
performed); or
2) The claim recovery action resulted in a Medicare adjusted payment amount
that is equal to or greater than the amount of the inpatient hospital deductible.
Prior to sending RAC-initiated adjustment claims with all other type of bill
designations (bill types other than 11X and 12X) to CWF for normal processing, the
Part A shared system shall input an “R” indicator in the newly defined header field of the
HUOP, HUHH, and HUHC claim transaction.

Prior to sending their processed RAC adjustment transactions to CWF for normal
verification and validation, the Part B and DME MAC shared systems shall input an “R”
indicator in the newly defined header field of their HUBC and HUDC claim transactions.
(See chapter 28, §70.6 for more details.)
CWF Actions
Upon receipt of a claim that contains an “R” in its header in the newly defined field,
CWF shall take the additional following actions:
1) Verify that the claim’s action code=3, entry code=5, or header claim adjustment
indicator=A;
2) Check the COIF to determine if the COBA trading partner wishes to include RAC-
initiated claims;
3) Include the claim for crossover, unless the “original” claim was not crossed over
(logic for crossover disposition indicator “R”) or the claim meets any other claims
exclusions specified on the COIF; or
4) Exclude the claim if the COIF specifies exclusion of RAC-initiated adjustment claims.
In addition, if the incoming HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim
contains spaces in the new designated RAC adjustment indicator field, CWF shall select
the claim in accordance with the COBA trading partner’s claims selection criteria, as
specified on the COIF.
80.9 - Health Insurance Portability and Accountability Act (HIPAA)
5010 and National Council for Prescription Drug Programs (NCPDP)
D.0 Crossover Requirements
(Rev. 4009, Issued: 03-23-18, Effective: 04-23-18, Implementation: 04-23-18)
Effective January 5, 2009, the BCRC 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).
The CWF maintainer shall 1) create these new fields, along with 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. If the BCRC transmits a value
other than T, P, or N within the newly designated fields, CWF shall ignore the value.
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.

The CWF shall not post crossover disposition indicators in association with claims whose
5010 and NCPDP D.0 indicators are “N” or “T.” (Refer to §80.5 of this chapter for more
information regarding claims crossover disposition indicators.)
80.10 - Inclusion and Exclusion of Specified Part B Claims for
Coordination of Benefits Agreement (COBA) Crossover Purposes
(Rev. 4474, Issued; 12-06-19, Effective: 01-04-20, Implementation: 01-06-20)
Effective April 6, 2020, CWF shall begin to support the inclusion and exclusion of Part B
psychotherapy claims via the COBA crossover process.
Inclusion of Part B Psychotherapy Claims
When CWF determines through reading the modified COBA Insurance File (COIF) that
a COBA trading partner wants to receive Part B psychotherapy claims only, it shall
select the claim for crossover purposes under the following circumstances:
• 	The claim’s Part B psychotherapy provider specialty code (i.e., code 26, 62, 68,
80, or 89), as received via the Health Utilization Part B claim (HUBC)
transaction, matches the COIF specifications for inclusion of Part B
psychotherapy claims; and
• 	The claim does not otherwise meet other exclusion logic specified on the COIF;
and
• 	As applicable, the corresponding original claim was not previously excluded from
crossing over. (Note: This relates to the CWF crossover disposition code “R”
logic and applies to adjustment claims. See Section 80.5 for more information
regarding crossover disposition code R.)
Exclusion of Part B Psychotherapy Claims
In determining whether a base COBA trading partner (i.e., an insurer or other health
benefit organization that carves out the processing and payment of mental health claims
to another organization) wishes to exclude Part B psychotherapy claims through the
COBA process, CWF shall:
• 	Verify if the claim's Part B psychotherapy provider specialty code matches the
COBA trading partner's exclusion criteria per the COIF; and
• 	Exclude the claim if a match is found.
Important: The CWF maintainer shall permit the inclusion or exclusion of some or all
Part B psychotherapy provider specialty codes in accordance with the information
specified on the COIF.
Crossover Disposition Indicators

CWF shall create a new COBA crossover disposition indicator “AG” (see Section 80.5
for further details regarding this crossover disposition indicator) that it will apply when
the HUBC claim does not meet the provider specialty code inclusion criteria.
In addition, CWF shall create a new COBA crossover disposition indicator “AH” (see
Section 80.5) that it will apply when the base COBA trading partner specifies it wishes to
exclude Part B psychotherapy claims from crossing over.
As applicable, CWF shall display the new “AG” and “AH” crossover disposition
indicators on page 2 of the PTBL claims detail screen on HIMR.

Transmittals Issued for this Chapter
Rev # 	Issue Date Subject 	Impl Date 	CR#
R13314CP 07/24/2025 Modifications to the National
Coordination of Benefits Agreement
(COBA) Medicare Claims Crossover
Process
01/05/2026 	14139
R11427CP 05/20/2022 Claims Processing Manual Update - Pub.
100.04 for Elimination of Certificates of
Medical Necessity (CMNs) and Durable
Medical Equipment Forms (DIFs)
01/03/2023 	12734
R11414CP 05/12/2022 Claims Processing Manual Update - Pub.
100.04 for Elimination of Certificates of
Medical Necessity (CMNs) and Durable
Medical Equipment Forms (DIFs) -
Rescinded and replaced by Transmittal
11427
06/13/2022 	12734
R11396CP 05/04/2022 Update to Chapters 3, 4, 27 and 37 of
Publication (Pub.) 100-04 Medicare
Claims Processing Manual to Remove
Reference to the Term "OSCAR"
10/03/2022 	12715
12/06/2019 Updates to the Coordination of Benefits
Agreement Insurance File (COIF) For Use
in the National Coordination of Benefits
Agreement (COBA) Crossover Process
04/06/2020 	11380
R4454CP 	11/08/2019 Updates to the Coordination of Benefits
Agreement Insurance File (COIF) For Use
in the National Coordination of Benefits
Agreement (COBA) Crossover Process-
Rescinded and replaced by Transmittal
4474
04/06/2020 	11380
R4220CP 	01/25/2019 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process
07/01/2019 	11092
R4088CP 	07/13/2018 Update to the Internet Only Manual (IOM)
Publication 100-04 - Medicare Claims
Processing Manual, Chapter 27 -
08/14/2018 	10842

Rev # 	Issue Date Subject 	Impl Date 	CR#
Contractor Instructions for Common
Working File (CWF)
R4047CP 	05/11/2018 Updates to Publication 100-04, Chapters 1
and 27 to Replace Remittance Advice
Remark Code (RARC) MA61 with N382
08/13/2018 	10619
R4009CP 	03/23/2018 Update to the Internet Only Manual (IOM)
Publication 100-04 - Medicare Claims
Processing Manual, Chapter 27 -
Contractor Instructions for Common
Working File (CWF)
04/23/2018 	10497
R3765CP 	05/05/2017 Modifications to the Common Working
File (CWF) In Support of the
Coordination of Benefits Agreement
(COBA) Crossover Process
10/02/2017 	9967
R3468CP 	02/19/2016 Medicare Internet Only Manual (IOM)
Publication 100-04 Chapter 27 Contractor
Instructions for CWF
12/02/2015 	9293
R3386CP 	10/30/2015 Medicare Internet Only Manual (IOM)
Publication 100-04 Chapter 27 Contractor
Instructions for CWF – Rescinded and
replaced by Transmittal 3468
12/02/2015 	9293
R3358CP 	09/18/2015 Claims Processing Medicare Secondary
Payer (MSP) Policy and Procedures
Regarding Ongoing Responsibility for
Medicals (ORM)
07/06/2015 	8984
R3213CP 	03/06/2015 Claims Processing Medicare Secondary
Payer (MSP) Policy and Procedures
Regarding Ongoing Responsibility for
Medicals (ORM) – Rescinded and
replaced by Transmittal 3358
07/06/2015 	8984
R3167CP 	01/15/2015 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process
04/06/2015 	8878

Rev # 	Issue Date Subject 	Impl Date 	CR#
R3115CP 	11/06/2014 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process – Rescinded
and replaced by Transmittal 3167
04/06/2015 	8878
R2810CP 	11/07/2013 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process
04/07/2014 	8454
R2670CP 	03/14/2013 Modification to CWF, FISS, MCS and
VMS to Return Submitted Information
When There is a CWF Name and HIC
Number Mismatch
10/01/2012 	7260
R2515CP 	08/08/2012 Handling Form CMS-1500 Hard Copy
Claims Where and ICD-9-C< “E” Code or
Where and ICD-10 V00-Y99 Code is
Reported as the First Diagnosis on the
Claim
01/07/2013 	7700
R2449CP 	04/26/2012 Modification to CWF, FISS, MCS and
VMS to Return Submitted Information
When There is a CWF Name and HIC
Number Mismatch – Rescinded and
replaced by Transmittal 2670
10/01/2012 	7260
R2229CP 	05/25/2011 Modifications to the Common Working
File (CWF) Logic In Support of the
National Coordination of Benefits
Agreement (COBA) Crossover Process
07/05/2011 	6741
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

Rev # 	Issue Date Subject 	Impl Date 	CR#
R2138CP 	01/21/2011 Modifications to the Common Working
File (CWF) Logic In Support of the
National Coordination of Benefits
Agreement (COBA) Crossover Process –
Rescinded and replaced by Transmittal
2229
07/05/2011 	6741
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
R1893CP 	01/15/2010 Paying Claims Without Common
Working File (CWF) Approval
04/01/2010 	6764
R1793CP 	08/07/2009 Revision to the Selection Criteria for
Recovery Audit Contractor (RAC)
Adjustment Crossover Claims and for
Fully Reimbursable Part B Claims
01/04/2010 	6567
R1704CP 	03/20/2009 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process
07/06/2009
and
10/05/2009
6343
R1703CP 	03/20/2009 Common Working File (CWF) Medicare
Secondary Payer (MSP) Type for Workers
Compensation Medicare Set-Aside
Arrangements (WCMSAs) to Stop
Conditional Payments
04/06/2009/
07/06/2009
5371
R1665CP 	01/09/2009 Common Working File (CWF) Medicare
Secondary Payer (MSP) Type for Workers
Compensation Medicare Set-Aside
Arrangements (WCMSAs) to Stop
Conditional Payments - Rescinded and
replaced by Transmittal 1703
04/06/2009/
07/06/2009
5371
R1588CP 	09/05/2008 Beneficiary Submitted Claims 	08/18/2008 	5683

Rev # 	Issue Date Subject 	Impl Date 	CR#
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
R1557CP 	07/18/2008 Beneficiary Submitted Claims - Rescinded
and replaced by Transmittal 1588
08/18/2008 	5683
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
R1399CP 	12/19/2007 Handling Personal Identifiable
Information on the Medicare Summary
Notice
01/07/2008 	5770
R1360CP 	11/02/2007 Modifications to the Coordination of
Benefits Agreement (COBA) Common
Working File
04/07/2008 	5766
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

Rev # 	Issue Date Subject 	Impl Date 	CR#
R1242CP 	05/18/2007 Transitioning the Mandatory Medigap
(“Claim Based”) Crossover Process to the
Coordination of Benefits Contractor
(COBC) - Replaced by Transmittal 1296
10/01/2007 	5601
R1232CP 	04/27/2007 Modifications to the National
Coordination of Benefits Agreement
(COBA) Crossover Process
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
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
R1038CP 	08/25/2006 The Coordination of Benefits Agreement
(COBA) Eligibility File Claims 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
R980CP 	06/14/2006 Changes Conforming to CR 3648
Instructions for Therapy Services -
Replaces Rev. 941
10/02/2006 	4014
R967CP 	05/26/2006 Modification to the Coordination of
Benefits Agreement (COBA) Claims
10/02/2006 	5094

Rev # 	Issue Date Subject 	Impl Date 	CR#
Selection Criteria and File Transfer
Protocols
R941CP 	05/05/2006 Changes Conforming to CR 3648
Instructions for Therapy Services
10/02/2006 	4014
R533CP 	04/29/2005 Modification to the Common Working
File (CWF) Edit Process for Non-
Assigned Medicaid Coordination of
Benefits Agreement (COBA) Crossover
Claims
07/05/2005 	3842
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
R001CP 	10/01/2003 Initial Publication of Manual 	NA 	NA
Back to top of Chapter