CMS Pub. 100-04, ch. 28
Table of Contents (Rev. 13314; Issued:07-24-25)
10 - Medigap - Definition and Scope
20 - Assignment of Claims and Transfer Policy
20.1 - Beneficiary Insurance Assignment Selection
30 - Completion of the Claim Form
30.1 - ASC X12 837 Professional/Form CMS-1500 COB
30.2 - ASC X12 837 Institutional/Form CMS 1450 COB
40 - MSN Messages
50 - Remittance Notice Messages
60 - Returned Medigap Notices
70 - Coordination of Medicare With Medigap and Other Complementary Health Insurance Policies
70.1 - Authorization for Release of Information
70.1.1 - Requests for Additional Information
70.1.2 - Release of Title XVIII Claims Information for Medigap Insurance Purposes by Providers
70.2 - Integration of Title XVIII Claims Processing With Complementary Insurance Claims Processing
70.2.1 - Program Recognition
70.2.2 - Records and Information
70.2.3 - Matching Files Against Medicare Claims Files
70.3 - Standard Medicare Charges for COB Records
70.4 - General Guidelines for A/B MAC (A, B, or HH) or DME MAC Transfer of Claims Information to Medigap Insurers
70.5 - Audits
70.6 - Consolidation of the Claims Crossover Process
70.6.1 - Coordination of Benefits Agreement (COBA) Detailed Error Report Notification Process
70.6.1.1 - Coordination of Benefits Agreement (COBA) ASC X12 837 5010 Coordination of Benefits (COB) Flat File Errors
70.6.2 - Coordination of Benefits Agreement (COBA) Full Claim File Repair Process
70.6.3 - Coordination of Benefits Agreement (COBA) Eligibility File Claims Recovery Process
70.6.4 - Coordination of Benefits Agreement (COBA) Medigap Claim-Based Crossover Process
70.6.5 - Coordination of Benefits Agreement (COBA) ASC X12 837 Coordination of Benefits (COB) Mapping Requirements as of July 2012
70.6.6 - National Council for Prescription Drug Programs (NCPDP) Version D.0 Coordination of Benefits (COB) Mapping Requirements
80.1 - Deleted - Reserved
80.2 - Deleted - Reserved
80.3 - Medigap Electronic Claims Transfer Agreements
80.3.1 - A/B MAC (A)/A/B MAC (HH) Crossover Claim Requirements
80.3.2 - A/B MAC/DME MAC Crossover Claim Requirements
110.1 - Outline of Complaint Referral Process
110.2 - Preliminary Screening and Referral to Regional Office of the Inspector General
110.3 - CMS Regional Office Quarterly Report on Medicare Supplemental Health Insurance Penalty Provision Activity
110.3.1 - Statistics
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The Omnibus Budget Reconciliation Act of 1990 (OBRA 1990, Public Law 101-508) requires all Medicare supplemental (Medigap) insurance policies to conform to minimum standards including loss ratio requirements, standardized benefit packages and consumer protection requirements.
The procedures described in §§20 through 110 apply to all policies meeting the definition of Medicare supplemental insurance policies ('Medigap') in §1882(g)(1) of the Social Security Act (the Act.).
A Medigap policy is defined as: A group or individual policy of accident and sickness insurance, or a subscriber contract of hospital and medical service associations or health maintenance organizations, other than a policy issued pursuant to a contract under §1876 or §1833 of the Act, or a policy issued under a demonstration project.
A Medigap policy is offered by a private company to those entitled to Medicare benefits and provides payment for Medicare charges not payable because of the applicability of deductibles, coinsurance amounts or other Medicare imposed limitations. Typically, a Medigap policy does not include limited benefit coverage areas available to Medicare beneficiaries, such as 'specified disease' or 'hospital indemnity' coverage. By law, the definition explicitly excludes a policy or plan offered by an employer to employees, or former employees, as well as policies offered by a labor organization to members or former members.
The National Association of Insurance Commissioners has developed model regulatory language for State insurance commissions to apply to Medigap insurance offerings. This model regulatory language is located at: http://www.carfra.com/products/medsupappendixb.pdf. It recommends the requirements that states should consider for approving proposed Medigap insurance plans.
The following procedures for furnishing information are mandatory for Medigap plans. Medicaid agencies are furnished information in the standard format free of charge. Other commercial payers, including Medigap insurers, must pay a CMS established per claim crossover fee for providing them with Medicare paid claims data.
(Rev. 4069, Issued: 06-08 – 18, Effective: 07- 09- 18, Implementation: 07- 09-18)
A Medicare beneficiary who has a Medigap policy may authorize the participating physician/practitioner or supplier of services to file a claim on his or her behalf and to receive payment directly from the insurer instead of through the beneficiary. In such cases, Medicare must transfer Medicare claims information to the Medigap insurer. The Medigap insurer pays the physician/provider/supplier directly. The Medigap insurer, in turn, reimburses CMS's designated COBA contractor for the costs in supplying the information subject to limitations.
Paid claims from participating physicians or providers/suppliers for beneficiaries who have assigned their right to payment under a Medigap policy, regardless of whether or not it is in or from a State with an approved Medigap program, are to result in the transfer of claim information to the specified insurers.
The A/B MAC (Part B) and DME MAC systems must have the capability to distinguish between claims of participating and nonparticipating physicians/practitioners and suppliers. This is because Medigap assignment of claims and transfer policy does not apply to nonparticipating physicians/practitioners or non-participating suppliers.
Effective with the future implementation of CMS's consolidated Medigap claim-based crossover initiative, the process for reporting Medigap information on incoming claims will change. Each Part B physician/practitioner and supplier of durable medical equipment, prosthetics, orthotics, and medical supplies (DMEPOS) will only include the CMS-issued Medigap claim-based COBA ID (ID range 55000 through 55999), which will be assigned by CMS's Benefits Coordination & Recovery Center (BCRC), if: (1) the physician/practitioner or supplier participates in the Medicare Program; and (2) the beneficiary has assigned his/her rights to payment under a Medigap policy to that provider or supplier.
(Rev. 4281, Issued: 04- 19-19, Effective: 05-20-19, Implementation: 05-20-19)
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.
Beneficiaries indicate that they have assigned their Medigap benefits to a participating physician/practitioner or supplier by signing block #13 on the Form CMS-1500. This authorization is in addition to their assignment of Medicare benefits as indicated by their signature in block #12.
Form CMS-1450 makes no provision for the provider to indicate that the beneficiary has assigned benefits because the Form CMS-1450 is used only for institutional claims, for which payment is typically assigned to the provider of services. For claims the institutional provider submits to A/B MACs (B) for physician payments for physician employees; hospitals, SNFs, HHAs, OPTs, CORFs, or ESRD facilities may maintain a beneficiary statement in file instead of submitting a separate statement with each claim. This authorization must be insurer specific.
If the beneficiary has a Medigap policy, the following statement should be signed:
| NAME OF BENEFICIARY | Beneficiary's Medicare beneficiary identifier MEDIGAP POLICY NUMBER |
|---|---|
I request that payment of authorized Medigap benefits be made either to me or on my behalf to ___ for any services furnished me by that physician/provider/supplier. I authorize any holder of medical information about me to release to (name of Medigap insurer) any information needed to determine these benefits or the benefits payable for related services.
Since the beneficiary may selectively authorize Medigap assignments, caution providers about routinely stamping item #13 of the Form CMS-1500 "signature on file." The Medigap assignment on file in the participating doctor/supplier's office must be insurer specific. However, it may state that the authorization applies to all occasions of services until it is revoked.
Effective with October 1, 2007, participating Part B physicians/practitioners and DMEPOS suppliers now will only include the CMS-assigned Medigap claim-based COBA ID on an incoming claim if confirmation that a beneficiary has authorized Medigap assignment has been obtained.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
As part of the national Coordination of Benefits Agreement (COBA) claim-based Medigap crossover process, participating physicians/practitioners and suppliers that are attempting to trigger mandatory
Medigap (“claim-based”) crossovers must include the CMS-assigned 5-digit Medigap COBA claim-based ID (within range 55000 through 55999) within designated areas on the appropriate claim as follows:
In addition, unless otherwise specified, retail chain pharmacies that are attempting to trigger crossovers to their clients’ Medigap insurers should enter the Medigap COBA claim-based within field 301-C1 of the T04 segment on the incoming National Council for Prescription Drug Programs (NCPDP) batch claims. For more information regarding the COBA Medigap claim-based crossover process, refer to §70.6.4 of this chapter.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Participating physicians/practitioners and suppliers sign an agreement with Medicare to accept assignment of Medicare benefits for all Medicare patients. A claim for which a beneficiary elects to assign his/her benefits under a Medigap policy to a participating physician/practitioner and supplier is called a “mandated Medigap transfer.”
Participating providers and suppliers that must bill electronically shall enter the 5-digit claim-based Medigap COBA ID in field NM109 of the NM1 segment in loop 2330B of the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 837 professional claim for purposes of triggering Medigap claim-based crossovers. If a participating Part B physician/practitioner or DMEPOS supplier fails to include this identifier in the field just described, the claim will not be transferred, as appropriate, to the Medigap insurer via the COBA claim-based Medigap crossover process.
Under CMS’s national COBA claim-based Medigap process, participating Part B physicians/practitioners and suppliers that are exempted under the Administrative Simplification Compliance Act (ASCA) from having to bill electronically are required to enter the CMS-assigned 5-digit claim-based Medigap COBA ID on the paper form.
Medigap information is entered on the CMS Form 1500 as follows:
Item 9a - The policy and/or group number of the Medigap insured preceded by MEDIGAP, MG, or MGAP. Note - item 9d must be completed if a policy and/or group number is entered in item 9a.
Item 9b - The Medigap insured’s 8-digit date of birth (MM|DD|CCYY) and sex.
Item 9c - Blank if item 9(d) is completed. Otherwise, the claims processing address of the Medigap insurer. An abbreviated street address, two-letter postal code, and ZIP Code copied from the Medigap insured’s Medigap identification card is entered. For example:
1257 Anywhere Street Baltimore, Md. 21204 Is shown as 1257 Anywhere St. MD 21204
Item 9d - Enter the Coordination of Benefits Agreement (COBA) Medigap claim-based Identifier (ID). Refer to chapter 28, section 70.6.4, of this manual for more information.”
All the information in items 9, 9a, 9 b, and 9d must be complete and accurate. Otherwise, the A/B MAC (B) or DME MAC cannot forward the claim information.
Item 9a - Enter the policy and/or group number of the Medigap insured preceded by MEDIGAP, MG, or MGAP.
Note - item 9d must be completed if a policy and/or group number is entered in item 9a.
Item 9b - Leave blank.
Item 9c - Leave blank if item 9d is completed. Otherwise, enter the claims processing address of the Medigap insurer. Use an abbreviated street address, two-letter postal code, and ZIP Code copied from the Medigap insured’s Medigap identification card. For example:
1257 Anywhere Street Baltimore, Md. 21204 Is shown as 1257 Anywhere St. MD 21204
Item 9d - Enter the Coordination of Benefits (COBA) Medigap claim-based identifier (ID). See Chapter 28, §70.6.4 for more information.
All the information in items 9, 9a, and 9d must be complete and accurate. Otherwise, the A/B MAC (B) or DME MAC cannot forward the claim information.
Retail pharmacies that wish to trigger claim-based crossovers to Medigap insurers shall enter the Medigap claim-based COBA ID within field 301-C1 of the T04 segment of the NCPDP claim.
In accordance with the language provided within §1842(h)(3)(B) of the Social Security Act, no information entered on an incoming Form CMS-1450 or incoming Health Insurance Portability Act (HIPAA) ASC X12 837 institutional claim (current format) shall result in a process whereby CMS transfers the claim to a Medigap insurer.
A Medicare beneficiary who has a Medigap policy may authorize the participating physician/practitioner or supplier of services to file a claim on his or her behalf and to receive payment directly from the insurer instead of through the beneficiary. In such cases, Medicare must transfer Medicare claims information to the Medigap insurer. The Medigap insurer pays the physician/provider/supplier directly. The Medigap insurer, in turn, reimburses CMS’s designated COBA contractor for the costs in supplying the information subject to limitations.
Paid claims from participating physicians or providers/suppliers for beneficiaries who have assigned their right to payment under a Medigap policy, regardless of whether or not it is in or from a State with an approved Medigap program, are to result in the transfer of claim information to the specified insurers.
The A/B MAC (Part B) and DME MAC systems must have the capability to distinguish between claims of participating and nonparticipating physicians/practitioners and suppliers. This is because Medigap assignment of claims and transfer policy does not apply to nonparticipating physicians/practitioners or non-participating suppliers.
Effective with the future implementation of CMS’s consolidated Medigap claim-based crossover initiative, the process for reporting Medigap information on incoming claims will change. Each Part B physician/practitioner and supplier of durable medical equipment, prosthetics, orthotics, and medical supplies (DMEPOS) will only include the CMS-issued Medigap claim-based COBA ID (ID range 55000 through 55999), which will be assigned by CMS’s Benefits Coordination & Recovery Center (BCRC), if: (1) the physician/practitioner or supplier participates in the Medicare Program; and (2) the beneficiary has assigned his/her rights to payment under a Medigap policy to that provider or supplier.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
All A/B MACs and DME MACs shall include the following message on remittance notices sent to participating physicians/practitioners and suppliers when Medigap benefits are assigned and the information in block #9 of the Form CMS-1500 (or FL50 of the Form CMS-1450, as appropriate) is completed:
MA 18 – “The claim information is also being forwarded to the patient’s supplemental insurer. Send any questions regarding supplemental benefits to them.”
If the information in block #9 of the Form CMS-1500 or FL50 of the Form CMS-1450 is incomplete, or more than one Medigap insurer was entered, MACs do not transmit a transaction record to the Medigap insurer. In such cases, the following message is included on the remittance advices.
MA19 - “Information was not sent to the Medigap insurer due to incorrect/invalid information you submitted concerning the insurer. Please verify your information and submit your secondary claim directly to that insurer.”
Beginning with the October 2004 systems release, all A/B MACs and DME MACs shall include COBA trading partner names on the provider Electronic Remittance Advice (ERA) following receipt of a Beneficiary Other Insurance (BOI) reply trailer 29. (See §70.6 of this Chapter for more details.)
(Rev. 4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)
A/B MACs (Part B) and DME MACs ceased this responsibility on October 1, 2007, when CMS’s BCRC assumed full responsibility for the COBA claim-based Medigap process.
(Rev. 4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)
For applicable policy on information sharing, see Pub 100-1, the Medicare General Information, Eligibility and Entitlement Manual, Chapter 6.
For applicable cost sharing policy, see Pub 100-06, the Medicare Financial Management Manual, Chapter 1.
Up to and including the final claims transferred under their pre-existing mandatory Medigap (claim-based) crossover processes (note: the 'final' claims should be those processed by the A/B MAC (Part B) or DME MAC just before the October 2007 release is installed), A/B MACs (Part B) and DME MACs should determine the frequency at which they routinely transmit notices to all Medigap insurers but must transmit not less often than monthly. (See §70.4)
Effective October 1, 2005, CMS fully consolidated the eligibility file-based claims crossover process, as it relates to Medigap insurers and other commercial payers, under the BCRC. Refer to §70.6 and succeeding sub-sections for A/B MAC (Part B) and DME MAC requirements and responsibilities relating to the national Coordination of Benefits Agreement (COBA) consolidated crossover process. Refer to §70.6.4 for all MAC requirements relating to the COBA Medigap claim-based crossover process, which was inaugurated on October 1, 2007. (See also Pub.100-04 chapter 27 §80.7.)
Following crossover consolidation, all A/B MACs (Part B) and DME MACs shall continue to pursue collection of unpaid debts from Medigap insurers and other existing trading partners, even after such entities have been transitioned to the COBA process. Those MACs that maintained claim-based crossover arrangements with Medigap insurers shall pursue collection of their invoices up through and including their invoices for the final claims transfer to the Medigap entities. These invoices should have been issued no later than one (1) month following the last claims transfer to the Medigap insurers.
Effective with April 2, 2007, all A/B MACs (Part B) and DME MACs shall suppress fully denied provider sanctioned claims for their mandatory Medigap crossover process with Medigap insurers, as authorized by §1842(h)(3)(B) of the Social Security Act and §4081(a)(B) of the Omnibus Budget Reconciliation Act of 1987 [Public Law 100-230].
NOTE: All A/B MACs (Part B) and DME MACs shall continue to suppress 100 percent paid and 100 percent denied claims from their mandatory Medigap crossovers, per previous CMS guidance.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual, Chapter 6.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
In the absence of a standing arrangement, the mere presence of an 'authorization' to release and the identification of a complementary insurer on a title XVIII billing form does not constitute a request for the 'release' of information. The request for the information must be specific.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Subject to specific written beneficiary authorization, providers, physicians/practitioners, and suppliers are permitted to furnish certain limited information about Medicare eligibility status and related claims information to other payers for complementary insurance purposes. (See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual for instructions about disclosure of information.
See Chapter 1 of Pub. 100-06, the Medicare Financial Management Manual, for requirements for determining costs.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Since title XVIII program identity must be maintained, notices and forms for title XVIII purposes must clearly identify their title XVIII origin. Also, they must not imply that title XVIII entitlement or enrollment is dependent upon the individual's retention of his/her complementary insurance policy.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 6, of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.
(Rev.4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.
The BCRC now has exclusive responsibility for the collection and reconciliation of crossover claim fees for those Medigap and non-Medigap claims that A/B MACs and DME MACs send to the BCRC to be crossed to trading partners.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
See chapter 1, of Pub 100-06, the Medicare Financial Management Manual.
(Rev. 13314; Issued: 07-24-25; Effective: 01-01-26; Implementation: 01-05-26)
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.
Through the Benefits Coordination & Recovery Center (BCRC), Medicare transmits outbound 837 Coordination of Benefit (COB) and Medigap claims to COB trading partners and Medigap plans, collectively termed 'trading partners,' on a post-adjudicative basis. This type of transaction, originating at individual A/B MACs and DME MACs following their claims adjudication activities, includes incoming claim data, as modified during adjudication if applicable, as well as payment data. All A/B MACs and DME MACs are required to accept all ASC X12 837 segments and data elements permitted by the in-force applicable guides on an initial ASC X12 837 professional or institutional claim from a provider, but they are not required to use every segment or data element for Medicare adjudication. Segments and data elements determined to be extraneous for Medicare claims adjudication shall, however, be retained by the A/B MACs (Part B) and DME MACs within its store-and-forward repository (SFR). Incoming claims data shall be subjected to standard syntax and applicable implementation guide (IG) edits prior to being deposited in the SFR to assure non-compliant data will not be forwarded on to another payer as part of the Medicare crossover process. SFR data shall be re-associated with those data elements used in Medicare claim adjudication, as well as with payment data, to create an ASC X12 837 IG-compliant outbound COB/Medigap transaction. The shared systems shall always retain the data in the SFR for a minimum of 6 months.
The ASC X12 837 institutional and professional implementation guides require that claims submitted for secondary payment contain standard claim adjustment reason codes (CARCs) to explain adjudicative decisions made by the primary payer. For a secondary claim to be valid, the amount paid by the primary payer plus the amounts adjusted by the primary payer shall equal the billed amount for the services in the claim. A tertiary payer to which Medicare may forward a claim may well need all data and adjustment codes Medicare receives on a claim. A tertiary payer could reject a claim forwarded by Medicare if the adjustment and payment data from the primary payer or from Medicare did not balance against the billed amounts for the services and the claim. As a result, shared systems shall reject inbound Medicare Secondary Payer (MSP) claims if the paid and adjusted amounts do not equal the billed amounts and if the claims lack standard CARCs to identify adjustments to the total amount billed.
As a rule, the shared system maintainers shall populate an outbound COB/Medigap file as an ASC X12 837 flat file with the Employer Identification Number (EIN)/Tax ID or SSN (for a sole practitioner) present in the provider's file, unless otherwise specified within §70.6.5 or §70.6.6 of this chapter. With the adoption of the National Provider Identifier (NPI), the shared system shall report qualifier XX in NM108 and the NPI value in NM109. The shared system shall report the provider's EIN/TAX ID within the REF segment of the billing provider loop, as appropriate. In addition, unless otherwise stated within §70.6.5 or §70.6.6 of this chapter, the shared systems shall populate the provider loops on outbound ASC X12 837 claims with the provider's first name, last name, middle initial, address, city, state and zip code as contained in the Medicare provider files, the information for which is derived from the Provider Enrollment Chain and Ownership System (PECOS).
The CMS has streamlined the claims crossover process to better serve its customers. Under the consolidated
claims crossover process, trading partners execute national agreements called Coordination of Benefits Agreements (COBAs) with CMS's BCRC. Through the COBA process, each COBA trading partner will send one national eligibility file that includes eligibility information for each Medicare beneficiary that it insures to the BCRC. The BCRC will transmit the beneficiary eligibility file(s) to the Common Working File (CWF) via the HUBO maintenance transaction. The transaction is also termed the "Beneficiary Other Insurance (BOI)" auxiliary file. (See Pub.100-04, chapter 27, §80.4 for more details about the contents of the BOI auxiliary file.)
During August 2003, the CMS modified CWF to accept both the HUBO (BOI) transaction on a regular basis and COBA Insurance File (COIF) as a weekly file replacement. Upon reading both the BOI and the COIF, CWF applies each COBA trading partner's claims selection criteria against processed claims with service dates that fall between the effective and termination date of one or more BOI records.
Upon receipt of a BOI reply trailer (29) that contains (a) COBA ID (s) and other crossover information required on the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 835 Electronic Remittance Advice (ERA), all A/B MACs and DME MACs shall send processed claims via an ASC X12 837 COB flat file or National Council for Prescription Drug Programs (NCPDP) file to the BCRC. The BCRC, in turn, will cross the claims to the COBA trading partner in the HIPAA ASC X12 837 or NCPDP formats, following its validation that the incoming Medicare claims are formatted correctly and pass HIPAA or NCPDP compliance editing.
In addition, CMS shall arrange for the invoicing of COBA trading partners for crossover fees.
For more information regarding the COBA Medigap claim-based crossover process, which was enacted on October 1, 2007, consult §70.6.4 of this chapter.
Effective with the January 2005 release, the A/B MAC (Part B) and DME MAC shared systems shall include an indicator "L" (beneficiary is liable for the denied service[s]) or "N" (beneficiary is not liable for the denied service[s]) in an available field on the HUBC and HUDC queries to CWF for claims on which all line items are denied. The liability indicators (L or N) shall be reflected at the header or claim level rather than at the line level.
For purposes of applying the liability indicator L or N at the header/claim level and, in turn, including such indicators in the HUBC or HUDC query to CWF, the A/B MACs (Part B) and DME MAC shared systems shall follow these business rules:
Effective with October 2007, the CWF maintainer shall create a 1-byte beneficiary liability indicator field within the header of its HUIP, HUOP, HUHH, and HUHC Part A claims transactions (valid values for the field="L," "N," or space).
As A/B MACs (Part A) and A/B MACs (Part HHH) adjudicate claims and determine that the beneficiary has payment liability for any part of the fully denied services or service lines, they shall set an “L” indicator within the newly created beneficiary liability field in the header of their HUIP, HUOP, HUHH, and HUHC claims that they transmit to CWF. In addition, as A/B MACs (Part A) and A/B MACs (Part HHH) adjudicate claims and determine that the beneficiary has no payment liability for any of the fully denied services or service lines - that is, the provider must absorb all costs for the fully denied claims - they shall include an “N” beneficiary indicator within the designated field in the header of their HUIP, HUOP, HUHH, and HUHC claims that they transmit to CWF. NOTE: A/B MACs (Part A) and A/B MACs (Part HHH) shall not set the “L” or “N” indicator on partially denied/partially paid claims.
Upon receipt of an HUIP, HUOP, HUHH, or HUHC claim that contains an “L” or “N” beneficiary liability indicator, CWF shall read the COBA Insurance File (COIF) to determine whether the COBA trading partner wishes to receive “original” fully denied claims with beneficiary liability (crossover indicator “G”) or without beneficiary liability (crossover indicator “F”) or “adjustment” fully denied claims with beneficiary liability (crossover indicator “U”) or without beneficiary liability (crossover indicator “T”).
If CWF determines that the COBA trading partner wishes to exclude the claim, as per the COIF, it shall suppress the claim from the crossover process.
CWF shall post the appropriate crossover disposition indicator in association with the adjudicated claim on the HIMR detailed history screen (see §80.5 of this chapter).
In addition, the CWF maintainer shall create and display the new 1-byte beneficiary liability indicator field within the HIMR detailed history screens (INPL, OUTL, HHAL, and HOSL), to illustrate the indicator (“L” or “N”) that appeared on the incoming HUIP, HUOP, HUHH, or HUHC claim transaction.
If an A/B MAC (Part A) or A/B MAC (Part HHH) sends values other than “L,” “N,” or space in the newly defined beneficiary liability field in the header of its HUIP, HUOP, HUHH, or HUHC claim, CWF shall reject the claim back to the A/B MAC for correction. Following receipt of the CWF rejection, the A/B MAC (Part A) and A/B MAC (Part HHH) shall change the incorrect value placed within the beneficiary liability field and retransmit the claim to CWF.
Effective with July 2007, in instances when CWF returns an error code 5600 to an A/B MAC and DME MAC, thereby causing it to reset the claim’s entry code to “5” and action code to “3,” the MAC shall set a newly developed “N”(non-adjustment) claim indicator (“treat as an original claim for crossover purposes”) in the header of the HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claim in the newly defined field before retransmitting the claim to CWF. The A/B MAC and DME MAC shared system shall then resend the claim to CWF.
Upon receipt of a claim that contains entry code “5” or action code “3” with a non-adjustment claim header value of “N,” the CWF shall treat the claim as if it were an “original” claim (i.e., as entry code “1” or action code “1”) for crossover inclusion or exclusion determinations. If CWF subsequently determines that the claim meets all other inclusion criteria, it shall mark the claim with an “A” (“claim was selected to be crossed over”) crossover disposition indicator.
Following receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) for the recycled claim, the A/B MACs’ and DME MACs’ shared systems shall ensure that, as part of their ASC X12 837 flat file creation
processes, they populate the 2300 loop CLM05-3 (Claim Frequency Type Code) segment with a value of “1” (original). In addition, the A/B MACs’ and DME MACs’ shared systems shall ensure that, as part of their ASC X12 837 flat file creation process, they do not create a corresponding 2330 loop REFT4Y segment, which typically signifies “adjustment.”
Effective with July 2007, in instances where A/B MACs and DME MACs must send adjustment claims to CWF as entry code “1” or as action code “1” (situations where CWF has rejected the claim with edit 6010), they shall set an “A” indicator in a newly defined field within the header of the HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC claim.
If A/B MACs and DME MACs send a value other than “A” or spaces within the newly designated header field within their HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims, CWF shall apply an edit to reject the claim back to the MAC. Upon receipt of the CWF rejection edit, the MACs’ systems shall correct the invalid value and retransmit the claim to CWF for verification and validation.
Upon receipt of a claim that contains entry code “1” or action code “1” with a header value of “A,” the CWF shall take the following actions:
NOTE: The expectation is that such claims do not represent mass adjustments tied to the MPFS or mass adjustments-other.
If A/ B MACs and DME MACs receive a BOI reply trailer (29) on a claim that had an “A” indicator set in its header, the A/B MACs’ or DME MACs’ systems shall ensure that, as part of their ASC X12 837 flat file creation processes, they populate the 2300 loop CLM05-3 (“Claim Frequency Type Code”) segment with a value that designates “adjustment” rather than “original” to match the 2330B loop REFT4Y that they create to designate “adjustment claim.”
If an A/B MAC’s or DME MAC’s shared system does not presently create a loop 2330B REFT4Y to designate adjustments, it shall not make a change to do so as part of this instruction.
If A/B MACs and DME MACs send a value other than “A,” “N,” or spaces within the newly designated header field within their HUBC, HUDC, HUIP, HUOP, HUHH, and HUHC claims, CWF shall apply an edit to reject the claim back to the A/B MAC or DME MAC. Upon receipt of the CWF rejection edit, the A/B MACs’ or DME MACs’ systems shall correct the invalid value and retransmit the claim to CWF for verification and validation.
Currently, the DME MAC shared system is able to identify, through the use of an internal indicator, whether a submitted claim is in the National Council for Prescription Drug Programs (NCPDP) format. Effective with January 2005, the DME MAC shared system shall pass an indicator “P” to CWF in an available field on the HUDC query when the claim is in the NCPDP format. The indicator “P” should be included in a field on the HUDC that is separate from the fields used to indicate whether a beneficiary is liable for all services that are
completely denied on his/her claim.
The CWF shall read the new indicators passed via the HUBC or HUDC queries for purposes of excluding 100 percent denied claims with or without beneficiary liability and NCPDP claims. After applying the claims selection options, CWF will return a BOI reply trailer (29) to the A/B MAC or DME MAC only in those instances when the COBA trading partner expects to receive a Medicare processed claim from the BCRC.
Effective with July 2007, CWF shall reject claims back to DME MACs if their HUDC claim contains a value other than “P” in the established field used to identify NCPDP claims.
Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUBC claim transmission for a 1-byte PQRI indicator (valid values=Q or space).
In addition, CWF shall create a 2-byte field on page 2 of the HIMR claim detail in association with the new category “COBA Bypass” for the value “BQ,” which shall designate that CWF auto-excluded the claim because it contained only PQRI codes (see §80.5 of this chapter for more details regarding the bypass indicator).
Prior to transmitting the claim to CWF for normal processing, the A/B MAC (Part B) shared system shall input the value “Q” in the newly defined PQRI field in the header of the HUBC when all service lines on a claim contain PQRI (status M) codes.
Upon receipt of a claim that contains a “Q” in the newly defined PQRI field (which signifies that the claim contains only PQRI codes on all service detail lines, CWF shall auto-exclude the claim from the national COBA eligibility file-based and Medigap claim-based crossover processes. Following exclusion of the claim, CWF shall populate the value “BQ” in association with the newly developed “COBA Bypass” field on page 2 of the HIMR A/B MAC (Part B) and DME MAC claim detail screens.
Prior to October 6, 2008, all A/B MACs and DME MACs shall update any of their provider customer service materials geared towards crossover claims related inquiries to reflect the newly developed “BQ” bypass value, which designates that CWF auto-excluded the claim because it only contained PQRI codes.
The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to reflect the new “BQ” code.
Effective October 6, 2008, the CWF maintainer shall create space within the header of its HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claims transactions for a new 1-byte “NPI-Placeholder” field (acceptable values=Y or space).
In addition, the CWF maintainer shall create space within page two (2) of the HIMR detail of the claim screen for 1) a new category “COBA Bypass”; and 2) a 2-byte field for the indicator “BN.” (See Pub. 100-04, chapter 27, §80.5 for more details regarding the “BN” bypass indicator.)
NOTE: With the implementation of the October 2008 release, the CWF maintainer shall remove all current logic for placeholder provider values with the implementation of this new solution for identifying claims that contain placeholder provider values.
As A/B MACs and DME MACs adjudicate non VA MRA claims that fall within any of the NPI placeholder requirements, their shared system shall take the following combined actions:
1) Input a “Y” value in the newly created “NPI Placeholder” field on the HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim transaction if a placeholder value exists on or is created anywhere within the SSM claim record. NOTE: The A/B MAC and DME MAC shared systems shall include spaces within the “NPI Placeholder” field when the claim does not contain a placeholder NPI value; and
2) Transmit the claim to CWF, as per normal requirements.
Upon receipt of claims where the NPI Placeholder field contains the value “Y,” CWF shall auto-exclude the claim from the national COBA crossover process. In addition, CWF shall populate the value “BN” in association with the newly developed “COBA Bypass” field on page 2 of the HIMR Part B and DME MAC claim detail screen and on page 3 of the HIMR intermediary claim detail screen. (See Pub.100-04, chapter 27, §80.4 for more details.)
Prior to October 6, 2008, all A/B MACs and DME MACs shall update any of their provider customer service materials geared towards crossover claims related inquiries to reflect the newly developed “BN” by-pass value, which designates that CWF auto-excluded the claim because it contained a placeholder provider value.
The Next Generation Desktop (NGD) contractor shall also modify its user screens and documentation to reflect the new “BN” code.
Effective with October 3, 2011, the CWF maintainer shall expand its logic for “Other Insurance,” which is COIF element 176, to include TRICARE for Life (COBA ID 60000-69999) and CHAMPVA (COBA ID 80214), along with State Medicaid Agencies (70000-79999), as entities eligible for this exclusion.
Through these changes, if either TRICARE for Life or CHAMPVA wishes to invoke the “Other Insurance” exclusion, and if element 176 is marked on the COIF for these entities, CWF shall suppress claims from the national COBA crossover process if it determines that the beneficiary has active additional supplemental coverage.
As part of this revised “Other Insurance” logic for TRICARE and CHAMPVA, CWF shall interpret “additional supplemental coverage” as including entities whose COBA identifiers fall in any of the following ranges:
00001-29999 (Supplemental); 30000-54999 (Medigap eligibility-based); 80000-80213 (Other Insurer); and 80215-88999 (Other Insurer).
The “Other Insurance” logic for State Medicaid Agencies includes all of the following COBA ID ranges:
00001-29999 (Supplemental); 30000-54999 (Medigap eligibility-based); 60000-69999 (TRICARE); 80000-80213 (Other Insurance) 80214 (CHAMPVA) 80215-88999 (Other Insurer).
NOTE: As of October 3, 2011, CWF shall now omit COBA ID range 89000-89999 as part of its Other Insurance logic for State Medicaid Agencies.
CWF shall mark claims that it excludes due to “Other Insurance” with crossover disposition indicator “M” when storing them within the CWF claims history screens. (See §80.5 of chapter 27 for additional information concerning this indicator.)
All A/ B MACs and DME MACs shall continue to identify mass adjustment claims—MPFS and mass adjustment claims—other by including an “M” (mass adjustment claims—MPFS) or “O” (mass adjustment claims—other) within the header of the HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claim transactions, as specified in Pub.100-04, chapter 27, §80.6. (Refer to Pub.100-04, chapter 27, §80.8 for CWF specific requirements relating to the unique inclusion of mass adjustment claims for crossover purposes.)
Effective January 5, 2009, the BCRC, at CMS’s direction, modified the COIF to allow for the unique inclusion of mass adjustment claims—MPFS updates and mass adjustment claims—other. The CWF maintainer shall 1) create these new fields, along with accompanying 1-byte file displacement, within its version of the COIF; and 2) accept and process these new fields when the BCRC transmits them as part of its regular COIF updates.
Upon receipt of a HUIP, HUOP, HUHH, HUHC, HUBC, or HUDC claim transaction that contains an “M” or “O” mass adjustment indicator, CWF shall undertake all additional actions with respect to determination as to whether the claim should be included or excluded for crossover purposes as specified in chapter 27, §80.8.
Before the A/B MAC and DME MAC shared systems send “mass adjustment claims—MPFS” to the BCRC via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:
1) Populate “ADD” in the field that corresponds to NTE01; and
2) Populate “MP,” utilizing bytes 01 through 02, in the field that corresponds to NTE02.
Before the A/B MAC and DME MAC shared systems send “mass adjustment claims—other” to the BCRC via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the 837 COB flat file only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:
1) Populate “ADD” in the field that corresponds to NTE01; and
2) Populate “MO,” utilizing bytes 01 through 02, in the field that corresponds to NTE02.
Effective January 5, 2009, at CMS’s direction, the BCRC modified the COIF to allow for the unique inclusion and exclusion of RAC-initiated adjustment claims. The CWF maintainer shall 1) create these new fields,
along with accompanying 1-byte file dis-placement, within its version of the COIF; and 2) accept and process these new fields when the BCRC transmits them as part of its regular COIF updates. In addition, the CWF maintainer shall create a 1-byte RAC adjustment value in the header of its HUIP, HUOP, HUHH, HUHC, HUBC, and HUDC claims transactions (valid values="R" or spaces).
Through this instruction, all A/B MAC and DME MAC shared systems shall develop a method for uniquely identifying all varieties of RAC-requested adjustments, which occur as the result of post-payment review activities.
NOTE: Currently, fewer than five (5) MACs process RAC adjustments.
Prior to sending its processed 11X and 12X type of bill RAC-initiated adjustment transactions to CWF for normal verification and validation, the A/B MAC (Part A) and A/B MAC (Part HHH) shared system shall input the "R" indicator in the newly defined header field of the HUIP claim transaction if the RAC adjustment claim meets either of the following conditions:
1) The claim resulted in Medicare changing its payment decision from paid to denied (i.e., Medicare paid $0.00 as a result of the adjustment performed); or
2) The claim resulted in a Medicare adjusted payment that falls below the amount of the inpatient hospital deductible.
Prior to sending RAC-initiated adjustment claims with all other type of bill designations to CWF for normal processing, the A/ B MAC (Part A) and A/B MAC (Part HHH) shared system shall input an "R" indicator in the newly defined header field of the HUOP, HUHH, and HUHC claim.
Prior to sending their processed RAC adjustment transactions to CWF for normal verification and validation, the A/B MAC (Part B) and DME MAC shared systems shall input the "R" indicator in the newly defined header field of the HUBC and HUDC claim transactions.
The BCRC will assign a unique COBA ID range (88000-88999) to COBA trading partners that elect to "include" RAC-initiated adjustment claims for crossover purposes and will not, at CMS's direction, charge the trading partner the standard crossover fee for that category of adjustment claims. Therefore, when A/B MACs and DME MACs receive a BOI reply trailer (29) on a claim that contains only a COBA ID in the range 88000 through 88999 (which designates RAC adjustment), the A/B MAC and DME MAC shall not expect payment for the claim.
Before the A/B MAC and DME MAC shared systems send "tagged" RAC-initiated adjustment claims to the BCRC via an ASC X12 837 flat file transmission, they shall take the following actions with respect to the fields that correspond to the loop 2300 NTE01 and NTE02 segments on the ASC X12 837 COB flat file only if there was not a pre-existing 2300 NTE segment on the incoming Medicare claim:
1) Populate "ADD" in the field that corresponds to NTE01; and
2) Populate "RA," utilizing bytes 01 through 02, in the field that corresponds to NTE02.
A. CWF Processing of the COBA Insurance File (COIF) and Returning of BOI Reply Trailers
Effective July 6, 2004, the BCRC began to send initial copies of the COBA Insurance File (COIF) to the nine CWF host sites. The COIF contains specific information that will identify the COBA trading partner, including name, COBA ID, address, and tax identification number (TIN). It also contains each trading partner's claims selection criteria along with an indicator (Y=Yes or N=No) of whether the trading partner wishes its name to be printed on the Medicare Summary Notice (MSN). Effective with the October 2004 systems release, the COIF also contains a 1-digit Test/Production Indicator that will identify whether a COBA trading partner is in test (T) or production (P) mode. The CWF shall return that information as part of the BOI reply trailer (29) to A/B MACs and DME MACs.
Upon receipt of a claim, CWF shall take the following actions:
For eligibility file-based crossover, all A/B MACs and DME MACs shall send processed claims information to the BCRC for crossover to a COBA trading partner in response to the receipt of a CWF BOI reply trailer (29). A/B MACs and DME MACs will only receive a BOI reply trailer (29) under the consolidated crossover process for claims that CWF has selected for crossover after reading each COBA trading partner's claims selection criteria as reported on the weekly COIF submission.
When a BOI reply trailer (29) is received, the COBA assigned ID will identify the type of crossover (see the Data Elements Required for the BOI Aux File Record Table in Chapter 27, §24). Although each COBA ID will consist of a five-digit prefix that will be all zeroes, A/B MACs and DME MACs are only responsible for picking up the last five digits within these ranges, which will be right justified in the COBA number field. In addition to the trading partner's COBA ID, the BOI reply trailer shall also include the COBA trading partner name (s), an "A" crossover indicator that specifies that the claim has been selected to be crossed over, and a one-digit indicator ["Y"=Yes; "N"=No] that specifies whether the COBA trading partner's name should be printed on the beneficiary MSN. As discussed above, effective with the October 2004 systems release, CWF shall also include a 1-digit Test/Production Indicator on the BOI reply trailer (29) that is returned to the A/B MACs and DME MACs.
Effective with the October 2004 systems release, the A/ B MACs and DME MACs began to receive BOI reply trailers (29) that contain an MSN indicator "Y" (Print trading partner name on MSN) or "N" (Do not print trading partner name on MSN).
When a COBA trading partner is in full production (Test/Production Indicator=P), the A/ B MAC
and DME MAC shall read the MSN indicator returned on the BOI reply trailer (29). If the A/B MAC or DME MAC receives an MSN indicator “N,” it shall print its generic crossover message(s) on the MSN rather than including the trading partner’s name. Examples of existing generic MSN messages include the following:
(For all COBA ID ranges other than Medigap)
MSN #35.1 - “This information is being sent to private insurer(s). Send any questions regarding your benefits to them.”
(For the Medigap COBA ID range)
MSN#35.2 - “We have sent your claim to your Medigap insurer. Send any questions regarding your Medigap benefits to them.”
Beginning with the October 2004 systems release, A/B MACs and DME MACs shall follow these procedures when determining whether to update its claims history to show that a beneficiary’s claim was selected by CWF to be crossed over.
Effective January 5, 2009, when CWF returns a BOI reply trailer (29) to an A/B MAC and DME MAC that contains only a COBA ID in the range 89000 through 89999, the A/B MAC and DME MAC shared system shall suppress all crossover information, including name of insurer and generic message#35.1, from all beneficiary MSNs.
A/B MACs and DME MACs shall not update their claims histories to reflect transference of “tagged” claims with COBA ID range 89000 through 89999 to the BCRC.
ASC X12 835 (Electronic Remittance Advice)/Provider Remittance Advice Crossover Messages
Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a “T” Test/Production Indicator to the A/B MACs and DME MACs, they shall not print information received from the BOI reply trailer (29) in the required crossover fields on the ASC X12 835 Electronic Remittance Advice or other provider remittance advices that are in production.
Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a “P” Test/Production Indicator to the A/B MACs and DME MACs, they shall use the returned BOI trailer information to take the following actions on the provider’s 835 Electronic Remittance Advice:
a. Input code 19 in CLP-02 (Claim Status Code) in Loop 2100 (Claim Payment Information) of the 835 ERA (v. 4010-A1). [NOTE: Record “20” in CLP-02 (Claim Status Code) in Loop 2100 (Claim Payment Information) when Medicare is the secondary payer.]
b. Update the 2100 Loop (Crossover Contractor Name) on the 835 ERA as follows:
NM101 [Entity Identifier Code]—Use “TT,” as specified in the 835 Implementation Guide.
NM102 [Entity Type Qualifier]—Use “2,” as specified in the 835 Implementation Guide.
NM103 [Name, Last or Organization Name]—Use the COBA trading partner’s name that accompanies the first sorted COBA ID returned to you on the BOI reply trailer.
NM108 [Identification Code Qualifier]—Use “PI” (Payer Identification)
NM109 [Identification Code]—Use the first COBA ID returned to you on the BOI reply trailer. (See line 24 of the BOI aux. file record
Effective with January 5, 2009, if CWF returns only COBA ID range 89000 through 89999 on a BOI reply trailer (29) to an A/B MAC and DME MAC, the associated shared system shall suppress all crossover information (the entire 2100 loop) on the 835 ERA.
Effective with October 3, 2011, when a beneficiary’s claim is associated with more than one COBA ID (i.e., the beneficiary has more than one health insurer/benefit plan that pays after Medicare), CWF shall sort the COBA IDs and trading partner names in the following order on the returned BOI reply trailer (29): 1) Eligibility-based Medigap (30000-54999); 2) Medigap claim-based (55000-59999); 3) Supplemental (00001-29999); 4) Other Insurer (80000-80213); 5) Other Insurance (80215-88999); 6) TRICARE (60000-69999); 7) CHAMPVA (80124); 8) Medicaid (70000-79999); and 9) Other-Health Care Pre-payment Plan [HCPP] (89000-89999). When two or more COBA IDs fall in the same range (see element 24 of the “Data Elements Required for the BOI Aux File Record” Table in chapter 27, §80.4 for more details), CWF shall sort numerically within the same range.
Effective January 5, 2009, the BCRC, at CMS’s direction, created a new 1-byte “5010 Test/Production Indicator” and a new 1-byte “NCPDP D.O Test/Production Indicator” on the COBA Insurance File [COIF] (valid values= “N”—not applicable or not ready as yet; “T”—test; “P”—production). In addition, the CWF maintainer shall add a new “5010 Test/Production Indicator” and an “NCPDP D.O Test/Production Indicator” to the BOI reply trailer (29) format. (See Pub.100-04 chapter 27, §80.7 for additional details regarding CWF requirements relating to the new crossover claim formats.)
Regardless of whether a COBA trading partner is in test mode (Test/Production Indicator returned via the BOI reply trailer 29=T) or production mode (Test/Production Indicator returned via the BOI reply trailer 29=P), A/B MACs and DME MACs shall transmit all non-NCPDP claims received with a COBA ID via a BOI reply trailer to the BCRC in an ASC X12 837 flat file, as described in Transmittal AB-03-060. In a separate transmission, DME MACs shall send the claims received in the NCPDP file format to the BCRC. A/B MACs and DME MACs shall enter the 5-digit COBA ID picked up from the BOI reply trailer (29) in the 1000B loop of the NM1 segment in the NM109 field. In a situation where multiple COBA IDs are received for a claim, A/B MACs and DME MACs shall send a separate ASC X12 837 or NCPDP transaction to the BCRC for each COBA ID. A/B MACs and DME MACs shall perform the transmission at the end of their regular batch cycle, when claims are removed from their payment floor, to ensure crossover claims are not processed by the COBA trading partner prior to Medicare’s final payment. Transmission to the BCRC shall occur via Connect: Direct or other CMS dictated connectivity.
Effective with October 4, 2005, when the A/B MAC and DME MAC shared systems transfer processed claims to the BCRC as part of the COBA process, they shall include an additional 1-digit alpha character (“T”=test or “P”=production) as part of the BHT03 identifier (Beginning of the Hierarchical Transaction Reference Identification) that is included within the ASC X12 837 flat file or NCPDP submissions. The shared systems shall determine that a COBA trading partner is in test or production mode by referring to the BOI reply trailer (29) originally received from CWF for the processed claim. (See §70.6.1 of this chapter for further details about the BHT03 identifier.)
Effective October 2, 2006, the Virtual Data Center (VDC), formerly the Enterprise Data Centers (EDCs), shall transmit a combined COBA “test” and “production” ASC X12 837 flat file and a combined “test” and “production” NCPDP file, as applicable, to the BCRC.
NOTE: This requirement changes the direction previously provided in October 2005 through the issuance of Transmittal 586.
With respect to ASC X12 837 COB flat file submissions to the BCRC, A/B MACs (Part B) and DME MACs shall observe these process rules:
The following segments shall not be passed to the BCRC:
1. ISA (Interchange Control Header Segment);
2. IEA (Interchange Control Trailer Segment);
3. GS (Functional Group Header Segment); and
4. GE (Functional Group Trailer Segment).
The 1000B loop of the NM1 segment denotes the crossover partner. If multiple COBA IDs are received via the BOI reply trailer, the shared system shall ensure that a separate ASC X12 837 transaction should be submitted for each COBA ID received. As the crossover partner information will be unknown to the standard systems, the following fields should be formatted as indicated for the NM1 segment:
NM103—Use spaces; and
NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).
The 2010BA loop denotes the subscriber information. If available, the subscriber name, address, and policy number should be used to complete the NM1, N3, and N4 segments. If unknown, the segments should be formatted as follows, with BCRC completing any missing information:
NM1 segment—For NM103, NM104, NM105, and NM107, use spaces;
NM1 segment—For NM109, include beneficiary’s Medicare beneficiary identifier;
N3 segment—Use all spaces; and
N4 segment—Use all spaces.
The 2010BB loop denotes the payer name. Per the HIPAA Implementation Guide (IG), this loop should define the secondary payer when sending the claim to the second destination payer. Consequently, given that the payer related to the COBA ID will be unknown by the standard systems, the NM1, N3, and N4 segments should be formatted as follows, with BCRC completing any missing information:
NM1 segment—For NM103, use spaces;
NM1 segment—For NM109, include the COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29);
N3 segment—Use all spaces; and
N4 segment—Use all spaces.
The 2330B loop denotes other payers for the claim. If multiple COBA IDs are returned via the BOI reply trailer, payer information for the additional COBA IDs will be unknown. As with the 2010BB loop, the NM1 segment should be formatted as follows, with BCRC completing any missing information:
NM103—Use spaces; and
NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).
The 2330B loop shall be repeated to allow for the inclusion of the name (NM103) and associated Trading Partner ID (NM109) for each existing trading partner.
The 2320 loop denotes other subscriber information. Within the SBR segment, the SBR03 and SBR04 segments are used to define the group/policy number and insured group name, respectively. If the information is available for these fields, those values should be propagated accordingly for both current trading partners and COBA trading partners. The BCRC will inspect these values for COBA related eligibility based claims and overlay as appropriate. Spaces should only be used for COBA-related situations.
SBR01—Treat as normally do.
With respect to ASC X12 837 COB flat file submissions to the BCRC, A/B MACs (Part A) and A/B MACs (Part HHH) shall observe these process rules:
As the ISA, IEA, and GS segments are included in the “100” record with other required segments, the “100” record must be passed to the BCRC. However, as the values for these segments will be recalculated, spaces may be placed in all of the fields related to the ISA, IEA, and GS segments.
The 1000B loop of the NM1 segment denotes the crossover trading partner. If multiple COBA IDs are received via the BOI reply trailer, the A/B MAC or DME MAC system shall ensure that a separate 837 transaction should be submitted for each COBA ID received. As the crossover trading partner information will be unknown to the standard systems, the following fields should be formatted as follows for the NM1 segment on the “100” record:
NM103—Use spaces; and
NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).
The 2010BA loop denotes the subscriber information. If available, the subscriber name, address, and policy number should be used to complete the NM1, N3, and N4 segments. If unknown, the segments should be formatted as follows for the “300” record, with BCRC completing any missing information:
NM1 segment – For NM103, NM104, NM105, and NM107, use spaces;
NM1 segment—For NM109, include beneficiary’s Medicare beneficiary identifier;
N3 segment—Use all spaces; and
N4 segment—Use all spaces.
The 2010BC loop denotes the payer name. Per the HIPAA IG, this loop should define the secondary payer when sending the claim to the second destination payer. Consequently, since the payer related to the COBA
ID will be unknown to the standard systems, the NM1, N3, and N4 segments should be formatted as follows for the “300” record, with BCRC completing any missing information:
NM1 segment—For NM103, use spaces;
NM1 segment—For NM109, include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29);
N3 segment—Use all spaces; and
N4 segment—Use all spaces.
The 2330B loop of the “575” record denotes other payers for the claim. If multiple COBA IDs are returned via the BOI reply trailer, payer information for the additional COBA IDs will be unknown. As with the 2010BC loop, the NM1 segment should be formatted as follows, with BCRC completing any missing information:
NM103—Use spaces; and
NM109—Include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29).
The 2330B loop shall be repeated to allow for the inclusion of the name (NM103) and associated Trading Partner ID (NM109) for each existing trading partner.
The 2320 loop denotes other subscriber information. Within the SBR segment, the SBR03 and SBR04 segments are used to define the group/policy number and insured group name, respectively. If the information is available for these fields, those values should be propagated accordingly. The BCRC will inspect these values for COBA related eligibility based claims and overlay as appropriate. Spaces should only be used for COBA-related situations.
SBR01—Treat as normally do.
Effective April 5, 2021, the COB&R system supporting the BCRC will transmit modified dataset names to the VDCs for the COBA Claims Response File (the File whereby the BCRC, through the COB&R system, conveys an acceptance of the flat file with the value “A” or rejection of the file with the value“R”). The VDCs shall be prepared to accept the following modified dataset names effective April 5, 2021:
Note the following definitions that apply to the above Claim Response File dataset names:
When an A/B MAC and DME MAC receives the reject indicator “R” via the Claims Response File, it is to retransmit the entire file to the BCRC. If the A/B MAC or DME MAC receives an acceptance indicator “A,” this confirms that its entire COB flat file or NCPDP file transmission was accepted. Once COB flat files or NCPDP files are accepted and translated into the appropriate outbound format(s), BCRC will cross the claims to the COBA trading partner. The format of the Claims Response File that will be returned to each A/B MAC and DME MAC by the BCRC, following its COB ASC X12 837 flat file or NCPDP file transmission, appears in the table below. (See §70.6.1 for specifications regarding the receipt and processing of the BCRC Detailed Error Reports.)
Claims Response File Layout (80 bytes)
| Field | Name | Size | Displacement | Description |
|---|---|---|---|---|
| 1 | A/B MAC or DME MAC Number | 5 | 1-5 | A/B MAC or DME MAC Identification Number |
| 2 | Transaction Set Control Number/Batch Number | 9 | 6-14 | Found within the ST02 data element from the ST segment of the ASC X12 837 flat file or in field 806-5C from the batch header of the NCPDP file. |
| 3 | Number of claims | 9 | 15-23 | Number of Claims contained in the ASC X12 837 flat file or NCPDP file. This is a numeric field that will be right justified and zero-filled. |
| 4 | Receipt Date | 8 | 24-31 | Receipt Date of ASC X12 837 flat file or NCPDP file in CCYYMMDD format |
| 5 | Accept/Reject indicator | 1 | 32 | Indicator of either the acceptance or rejection of the ASC X12 837 flat file or NCPDP file. Values will either be an “A” for accepted or “R” for rejected. |
| 6 | Filler | 48 | 33-80 | Spaces |
Claims response files will be returned to A/B MACs and DME MACs after receipt and initial processing of a claim file. Thus, for example, if an A/B MAC or DME MAC sends a COB flat file daily via the VDC, the BCRC will return a claim response file to that entity on a daily basis.
Effective April 5, 2021, VDC-transmitted ASC X12 COB 837 flat files and NCPDP files submitted by the VDC on behalf of each A/B MAC and DME MAC, as applicable, to the CMS Baltimore Data Center (BDC) to, in turn, be transmitted to the Coordination of Benefits & Recovery (COB&R) system supporting BCRC will be assigned the following file dataset names, regardless of whether a COBA trading partner is in test or production mode:
Note the following definitions that apply to the dataset names above:
Cxxxxx= C + the 5-digit MAC ID; e.g., 12302
Dyymmdd.Thhmsst = Current date and Time concatenated to literals D and T. (NOTE: This is optional for the VDCs to include, and if not present, CMS EFT will concatenate it.)
A/B MACs and DME MACs shall perform the ASC X12 837 flat file and NCPDP file transmission at the end of the regular batch cycle, when claims come off the payment floor, to ensure crossover claims are not processed by the trading partner prior to Medicare’s final payment.
Files transmitted by the VDC to the BCRC shall be stored for 51 business days from the date of transmission.
The file names for the Claims Response File returned to the A/B MAC and DME MAC via the VDC will be created as part of the NDM set-up process.
Outbound COB files transmitted by BCRC to the COBA trading partners will be maintained for 50 business days following the date of transmission.
Refer to §70.6.4 of this chapter for more information regarding this process.
a. A/ B MACs and DME MACs shall use the BCRC and CMS COBA Problem Inquiry Request Form to identify and send COBA related problems and issues to the COB contractor for research.
In order to track trading partner requests for research of 837 ASC X12 issues, CMS requires A/B MACs and DME MACs to submit a COBA Problem Inquiry Request Form to the BCRC or CMS. This process is being implemented to reduce the number of duplicate issues being researched and to ensure your requests are processed timely. The standard form enables CMS and BCRC to track issues through completion and manage the process of addressing post-COBA production issues. Upon receipt the submitter shall receive a response from the BCRC with the assigned contact information.
CMS is also requiring A/B MACs and DME MACs to use the COBA Problem Inquiry Request Form when requesting a BCRC representative to research a COBA issue. The combined BCRC-CMS COBA Problem Inquiry Request Form appears below.
Completed by Submitter – control number if applicable Write in this column only
| MAC ID# (Enter the A/B MAC or DME MAC ID # assigned by CMS) | ||
|---|---|---|
| MAC Reference ID (If applicable - BHT03) | ||
| Reported By (Enter submitter's last name, first name) | ||
| Date Submitted (Enter current date – MM/DD/YR) | ||
| Contact # (Enter submitter's phone #) | ||
| E-mail Address (Enter submitter's e-mail address) | ||
| COBA ID # | ||
| Description of Problem (Check applicable category) | ||
| ☐ | HIPAA Error Code | |
| ICN Date (Date file was transmitted to the BCRC) | ||
| HIPAA Error Code(s) | ||
| Part A/Part B/NCPDP Claim | ||
| ☐ | Technical Issue (Claims file transmission failures) | |
| File Name | ||
| Transmission Date | ||
| Summary of Issue- Provide detail of problem and note if back-up information will be faxed, e.g., Sample Claims to be Faxed on MM/DD/YR. Indicate whether you would like your issue on the next HIPAA issues log – do not include any PHI information on this form if sent via email. All PHI information must be submitted via fax to the BCRC to the attention of your BCRC representative at 646-458-6761. Do not include PHI information on the fax cover sheet. Claim examples of issues to be addressed must include the beneficiary Medicare beneficiary identifier and the claim ICN/DCN. | ||
| BCRC USE ONLY. Date: | Ticket #: |
All A/B MACs and DME MACs and their shared systems shall develop a method for differentiating “mass adjustments tied to the Medicare Physician Fee Schedule (MPFS) updates” and “all other mass adjustments” from all other kinds of adjustments and non-adjustment claims.
NOTE: For appropriate classification, all adjustments that do not represent “mass adjustments-MPFS” or “mass adjustments-other” shall be regarded as “other adjustments.”) DME MACs and their shared system shall only be required to identify mass adjustments-other, which represents a current functionality available within VMS. This is because DME MACs do not use pricing from the MPFS when processing their claims.
For COBA crossover purposes, a “mass adjustment” refers to an action that an A/B MAC or DME MAC undertakes using special software (e.g., Super-Op Events or Express Adjustments) to pull together claims with the anticipated purpose of making monetary changes to a high number of those claims. If, however,
A/B MACs and DME MACs do not have special software to perform high volume adjustments (i.e., typically adjustments to 100 or more claims), but instead must perform their high volume adjustments manually, this action also fulfills the definition of a “mass adjustment.”
Before A/B MACs and DME MACs cable their claims to CWF for verification and validation, they shall populate a 1-byte “mass adjustment” indicator in the header of their HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC entry code “5” or action code “3” claim transactions. The CWF maintainer shall create a new 1-byte field within the header of its HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC claims transactions for this purpose.
A/ B MACs and DME MACs shall determine whether the “M” or “O” indicator applies in relation to a given claim at the point that they initiate a mass adjustment action on that claim using a manual process or an automated adjustment process; e.g., Super Op Events or Express Adjustments. Upon making this determination, the A/B MACs and DME MACs and their shared systems shall populate one (1) of the following mass adjustment claim indicators, specific to the particular claim situation, within the header of the A/B MACs or DME MACs’ processed claims that they will cable to CWF for verification and validation:
“M”—if mass adjustment claim tied to an MPFS update; or
If A/B MACs and DME MACs send values other than “M” or “O” within the newly designated field within the header of their HUBC, HUDC, HUIP, HUOP, HUHH, or HUHC entry code “5” or action code “3” claims, CWF shall apply an edit to reject the claims back to the MAC. Upon receipt of the CWF rejection edit, the shared systems shall correct the invalid value and retransmit the claims to CWF for verification and validation.
Important: Effective January 5, 2026, CWF shall begin accepting the value “N” (defined as Affordable Care Act (ACA) mass adjustment) in the header of HUIP, HUOP, HUHH, or HUHC claims for situations where CMS specifically directs that ACA mass adjustments be initiated and processed. Additionally, CWF shall modify its Part A consistency edit 0045 to accept the new Mass Adjustment Indicator value of “N.” This value may be generated by the Part A shared system or by a MAC (A, HHH). Only in this scenario will the Part A shared system map the value “P” (Affordable Care Act mass adjustment) to the 23rd position of the BHT03 file identifier on outbound 837 crossover claims.
Effective January 5, 2009, at CMS’s direction, the BCRC assigned all COBA HCPP and HMO Cost Plan participants a unique 5-byte COBA ID that falls within the range 89000 through 89999. The CWF system shall accept the reporting of this COBA ID range.
Upon receipt of a BOI reply trailer (29) that contains only a COBA ID in the range 89000 through 89999, the A/B MAC and DME MAC shared systems shall suppress all crossover information (including name of the insurer; generic message; and specific code (for ASC X12 835, code MA-18; for MSN, code 35.1) indicating that the claim will be crossed over) from the associated ASC X12 835 remittance advice and beneficiary MSN. (See §70.6.1 of this chapter for A/B MAC or DME MAC requirements relating to the BCRC Detailed Error Report processes and receipt of claims that contain COBA ID range 89000 through 89999.)
Effective with the April 2009 release, the A/B MAC (Part A) and A/B MAC (Part HHH) shared system shall suppress sending the credit claim portion of the debit-credit pairing (that transaction which cancels the original claim) associated with each affiliated A/B MAC's (A, HHH) adjustment claims to the BCRC. Upon suppressing the credit claim, the A/B MAC (Part A) and A/B MAC (Part HHH) system shall mark the claims history of its affiliate MAC to reflect this action.
(Rev. 13314; Issued: 07-24-25; Effective: 01-01-26; Implementation: 01-05-26)
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.
Effective with the July 2005 release, CMS implemented an automated process to notify physicians/practitioners, suppliers, and providers that specific claims that were previously tagged by the Common Working File (CWF) for crossover will not be crossed over due to claim data errors. Claims transmitted via ASC X12 837 flat file by the A/B MAC and DME MAC shared systems to the Benefits Coordination & Recovery Center (BCRC) may be rejected at the flat file level, at a HIPAA ASC X12 pre-edit validation level, or by trading partners as part of a financial dispute arising from an invoice received.
Effective with the April 2005 release, the A/B MAC and DME MAC shared systems began to populate the BHT 03 (Beginning of Hierarchical Reference Identification) portion of their ASC X12 837 COB flat file submissions to the BCRC with a unique 22-digit identifier. This unique identifier will enable the BCRC to successfully tie a claim that is rejected by the BCRC at the flat file or HIPAA ASC X12 pre-edit validation levels as well as claims disputed by trading partners back to the original ASC X12 837 flat file submissions.
Effective October 4, 2005, A/ B MACs and DME MACs and their shared systems began to receive notification via the BCRC Detailed Error Reports, whose file layout structures appear below, that a COBA trading partner is in test or production mode via the BHT 03 identifier that is returned from the BCRC.
Effective April 3, 2011, all A/B MACs and DME MACs shall include an extra 1-byte 'Original versus Adjustment Claim Indicator' value within the BHT03 identifier on all ASC X12 837 institutional and professional claims they transmit to the BCRC for crossover purposes. The BCRC shall, in turn, return this value to the appropriate A/B MAC and DME MAC via the BCRC Detailed Error Report process. In addition, the DME MAC shared system shall send an additional 1-byte value (defined as 'reserved for future use') as spaces in field 504-F4 (Message) of the NCPDP flat file sent to the BCRC. The BCRC shall, in turn, also return this value to the appropriate DME MAC via the BCRC Detailed Error Report process.
Effective April 1, 2013, CMS added a new 1-byte Original versus Adjustment indicator to the suite of possible 1-byte options for position 23 of the BHT03 identifier, as reflected below.
Effective with April 7, 2014, CMS has added 2 new 1-byte Original versus Adjustment indicators to the suite of possible options for position 23 of the BHT03 identifier, as reflected below.
The A/B MAC and DME MAC shared systems shall populate the BHT 03 (Beginning of Hierarchical Transaction Reference Identification; field length=30 bytes) portion of their ASC X12 837 flat files that are sent to the BCRC for crossover with a 23-digit Contractor Reference Identifier (CRI). The identifier shall be formatted as follows:
a. A/B MAC or DME MAC number (9-bytes; until the 9-digit MAC number is used, report the 5-digit MAC number, left-justified, with spaces for the remaining 4 positions); b. Julian date as YYDDD (5 bytes); c. Sequence number (5 bytes; this number begins with "00001," so the sequence number should increment for each ST-SE envelope, which is specific to a trading partner, on a given Julian date); d. Claim version indicator (2 bytes, numeric, to denote claim version)
Acceptable values = 50 (for ASC X12 claims), and 20 (for NCPDP D.0 claims);
e. COBA Test/Production Indicator (1-byte alpha indicator; acceptable values = "T" [test] and "P" [production]) or "R" if the claims were recovered for a "production" COBA trading partner (see §70.6.3 of this chapter for more details; f. Original versus Adjustment Claim Indicator (1-byte alpha indicator); acceptable values are defined as the following:
E - for reprocessed claims that formerly included an electronic prescribing (e-RX) negative adjustment amount;
O - for original claims;
P - for Affordable Care Act or other congressional imperative mass adjustments;
M - for non-Affordable Care Act mass adjustments tied to Medicare Physician Fee Schedule (MPFS);
S - for mass adjustment claims—all others;
R - for RAC adjustment claims;
A - for routine adjustment claims, not previously classified; and
C – for CMS-directed mass adjustment action (use specified by CMS).
The following indicator is only applicable to FISS-generated claims:
V - Void/cancel only claim
The 23-digit CRI shall be left-justified in the BHT 03 segment of the 837 flat file, with spaces used for the remaining 8 positions. (NOTE: The CRI is unique inasmuch as no two files should ever contain the same combination of numbers.)
(Note: This action is requested because the use of "P" is only appropriate when CMS directs its MACs to reprocess large volumes of claims due to specific changes to ACA provisions. The value "P" shall remain in effect, but the value shall only be used as CMS directs.)
FISS shall ensure that its associated Part A MACs (AA, HHH) are able to comply with this requirement by virtue of the creation of a new Mass Adjustment Indicator field value of "N." FISS and its associated MACs shall only send this value to the Common Working File (CWF) when Affordable Care Act (ACA) mass adjustments are being created and processed in accordance with CMS direction (see Pub.100-04, chapter 27, section 80.6 for more information).
For MACs (Part B) to comply with this requirement, they shall take the following action:
o Review the HxxTCACT spi-tab to temporarily remove any records with a "P" indicator unless they are needed for CMS specifically directed mass adjustment transactions tied to a future ACA update.
• MACs (Part B) shall only trigger the value "M" for the 23rd position of the BHT03 file identifier in the following circumstance:
o When CMS has specifically directed them and/or their shared system(s) to mass adjust large volumes of claims (i.e., typically 1 million or greater) due to a needed change that has been implemented to the Medicare Physician Fee Schedule (MPFS), such that the approved amounts have been adjusted downward or upward due to a legislative or regulatory change.
(Note: This scenario is unique to MPFS changes only and would apply to an entire timeframe within a given year or a previous year, e.g., from January 1 to June 30 or, for the previous year, from January 1 through December 31.)
• For MACs (Part B) to comply with this request, they shall:
o Review the HxxTCACT spi-tab to temporarily remove any records with an "M" indicator unless they are needed for CMS specifically directed mass adjustment transactions tied to MPFS updates.
When CMS has directed MACs (Part B) to perform mass adjustments following an update to the MPFS, the MACs (Part B) shall continue to map the value "M" to the Mass Adjustment Indicator claim header field.
(Note: This action will ensure that the Common Working File has the information it needs to exclude mass adjustments/MPFS as applicable; see Pub.100-04, chapter 7, section 80.6 for more information regarding this subject.)
Important: MACs (Part B) shall not trigger the value "M" when they are merely correcting claims that were processed incorrectly due to a non- MPFS systematic issue (e.g., reprocessing a whole series of demonstration project claims because the claims originally were not processed with the appropriate demonstration project reduction amounts reflected). Instead, they shall trigger the value "S" for the 23rd position of the BHT03 file identifier for this scenario.
Unless CMS has directed the MACs to include the value 'C' in the 23rd position of the BHT03, MACs shall otherwise take action to trigger the value 'S' (mass adjustment--other) in the 23rd position of the BHT03 file identifier when adjudicating mass adjustment claims that do not represent bona-fide MPFS adjustments. This guidance applies unless the claims represent Recovery Audit Contractor (RAC) adjustment claims (which often are effectuated as mass adjustments), in which case the value 'R' shall be triggered.
As of January 5, 2026, all MACs shall continue to trigger value 'A' for routine adjustment claims (i.e., non-mass adjustment claims) in position 23 of the BHT03 file identifier. This would not apply when the MAC is handling RAC-related adjustments. For that scenario, the MAC would trigger the value 'R' for the 23rd position of the BHT03 file identifier.
Effective April 3, 2011, the DME MAC shared system shall also adopt a unique 23-digit format, referenced directly above under 'Populating the BHT 03 Portion of the ASC X12 837 Flat File.' However, prior to April 7, 2014, the system shall populate the unique 23-digit identifier (defined as 'future use') with spaces in field 504-F4 (Message) within the NCPDP file (field length=35 bytes). The DME MAC shared system shall populate the unique identifier, left justified, in the field. Spaces shall be used for the remaining bytes in the field.
Effective April 7, 2014, the DME MAC shared system shall ensure that its DME MACs have the ability to 1) execute actions that will result in the transmission of their HUDC claims to CWF with Mass Adjustment Indicator set to 'O'; and 2) transmit mass adjusted NCPDP D.0 COB claims to the BCRC under a 504-F04 (Message) field identifier of 'C' (CMS-directed mass adjustment action) or 'P' (mass adjustments tied to Affordable Care Act or Congressional/legislative mandate) as appropriate to the situation.
In addition, the DME MAC shared system shall ensure that all NCPDP D.0 crossover claims will now be sent to the BCRC with the 23rd byte 504-F04 (Message) field indicator completed, when appropriate, as indicated below.
O -- for all 'original' NCPDP D.0 claims transmitted;
A-- for 'routine adjustment claims' transmitted; and
R-- for recovery audit claims (RAC) adjustment claims transmitted.
The A/B MAC and DME MAC shared systems shall accept the BCRC Institutional, Professional, and NCPDP Detailed Error Reports received from the COB&R system supporting the BCRC.
Effective with April 5, 2021, the datasets that the COB&R system supporting BCRC will use to convey the BCRC Detailed Error Reports to the VDCs representing the MACs are as follows:
xxxx.FISP.HBADR.GHI.COB5ERR(+1) [For Institutional Claims]
xxxx.MCSP.HBXDR.ADyy5ERC(+1) [For Professional non-DMEPOS Claims]
xxxx.VMSP.COBC.A5010.ERROR.FILE(+1) [For Professional DMEPOS Claims]
The formats for each of the Detailed Error Reports appear below.
Beginning with July 2007, all A/B MAC and DME MAC systems shall no longer interpret the percentage values received for ASC X12 837 institutional and professional claim “222” and “333” errors via the BCRC Detailed Error Reports as if the values contained a 1-position implied decimal (e.g., “038” =3.8 percent). DME MACs shall also no longer interpret the percentage values received for NCPDP claims for “333” errors via the BCRC Detailed Error Report for such claims as if the values should contain a 1-position implied decimal.
In addition, A/B MACs and their systems shall now base their decision-making calculus for initiation of a claims repair of “111” (flat file) errors upon the number of errors received rather than upon an established percent parameter, as otherwise described within this section.
Effective with July 2009, the A/B MAC and DME MAC shared systems shall accept the modified versions of the BCRC Detailed Error Reports for institutional and professional claims as reflected below. As part of the July 2009 changes, the BCRC will, at CMS’s direction, expand the length of the “error description” field. (NOTE: This means that the shared systems shall therefore include the expanded error description code as part of their special provider notification letters.)
The Institutional Error File Layout, including summary portion, will be used for Part A claim files.
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Control Number | 9 | 9-17 |
| 3 | COBA ID | 10 | 18-27 |
| 4 | Subscriber ID/Medicare ID | 12 | 28-39 |
| 5 | Claim DCN/ICN | 14 | 40-53 |
| 6 | Record Number | 9 | 54-62 |
| 7 | Record/Loop Identifier | 6 | 63-68 |
| 8 | Segment | 3 | 69-71 |
| 9 | Element | 2 | 72-73 |
| 10 | Error Source Code | 3 | 74-76 ('111', '222', or '333') |
| 11 | Error/Trading Partner Dispute Code | 6 | 77-82 |
| 12 | Filler | 100 | 83-182 |
| 13 | Field Contents | 50 | 183-232 |
| 14 | BHT 03 Identifier | 30 | 233-262 (23 bytes used) |
| 15 | Claim DCN/ICN | 23 | 263-285 |
| 16 | Error Description | 300 | 286-585 |
| 17 | Filler | 15 | 586-600 |
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Total Number of Claims for Processing Date | 10 | 9-18 |
| 3 | Number of '111' Errors | 10 | 19-28 |
| 4 | Number of '222' Errors | 10 | 29-38 |
| 5 | Percentage of '222' Errors | 3 | 39-41 |
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 6 | Number of '333' Errors | 10 | 42-51 |
| 7 | Percentage of '333' Errors | 3 | 52-54 |
| 8 | Filler | 19 | 55-73 |
| 9 | Summary Record ID Error Source Code | 3 | 74-76 ('999') |
| 10 | Filler | 524 | 77-600 |
The Professional Error File Layout, including summary portion, will be used for Part B and DME MAC claim files.
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Control Number | 9 | 9-17 |
| 3 | COBA ID | 10 | 18-27 |
| 4 | Subscriber ID/Medicare ID | 12 | 28-39 |
| 5 | Claim DCN/ICN | 14 | 40-53 |
| 6 | Record Number | 9 | 54-62 |
| 7 | Record/Loop Identifier | 6 | 63-68 |
| 8 | Segment | 3 | 69-71 |
| 9 | Element | 2 | 72-73 |
| 10 | Error Source Code | 3 | 74-76 ('111', '222', '333') |
| 11 | Error/Trading Partner Dispute Code | 6 | 77-82 |
| 12 | Filler | 100 | 83-182 |
| 13 | Field Contents | 50 | 183-232 |
| 14 | BHT 03 Identifier | 30 | 233-262 (23 bytes used) |
| 15 | Claims DCN/ICN | 23 | 263-285 |
| 16 | Error Description | 300 | 286-858 |
| 17 | Filler | 15 | 586-600 |
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Total Number of Claims for Processing Date | 10 | 9-18 |
| 3 | Number of '111' Errors | 10 | 19-28 |
| 4 | Number of '222' Errors | 10 | 29-38 |
| 5 | Percentage of '222' Errors | 3 | 39-41 |
| 6 | Number of '333' Errors | 10 | 42-51 |
| 7 | Percentage of '333' Errors | 3 | 52-54 |
| 8 | Filler | 19 | 55-73 |
| 9 | Summary Record ID Error Source Code | 3 | 74-76 ('999') |
| 10 | Filler | 524 | 77-600 |
The NCPDP Error File Layout, including summary portion, will be used by DME MACs for Prescription Drug Claims
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Batch Number | 7 | 9-15 |
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 3 | COBA ID | 5 | 16-20 |
| 4 | Medicare ID | 12 | 21-32 |
| 5 | CCN | 14 | 33-46 |
| 6 | Record Number | 9 | 47-55 |
| 7 | Batch Record Type | 2 | 56-57 |
| 8 | Segment ID | 2 | 58-59 |
| 9 | Error Source Code | 3 | 60-62 ('111', or '333') |
| 10 | Error/Trading Partner Dispute Code | 6 | 63-68 |
| 11 | Error Description | 100 | 69-168 |
| 12 | Field Contents | 50 | 169-218 |
| 13 | Unique File Identifier | 30 | 219-248 (23 bytes used) |
| 14 | CCN | 23 | 249-271 |
| 15 | Filler | 18 | 272-289 |
| Field | Description | Field Size | Record Location |
|---|---|---|---|
| 1 | Date | 8 | 1-8 |
| 2 | Total Number of Claims for Processing Date | 10 | 9-18 |
| 3 | Number of '111' Errors | 10 | 19-28 |
| 4 | Number of '333' Errors | 10 | 29-38 |
| 5 | Percentage of '333' Errors | 3 | 39-41 |
| 6 | Filler | 18 | 42-59 |
| 7 | Summary Record ID Error Source Code | 3 | 60-62 ('999') |
| 10 | Filler | 524 | 63-289 |
If the BCRC has rejected back to the A/B MAC and DME MAC shared system for 2 or more COBA Identification Numbers (IDs), the shared system shall receive a separate error record for each COBA ID. Also, if a file submission from a shared system to the BCRC contains multiple provider, subscriber, or patient level errors for one COBA ID, the shared system will receive a separate error record for each provider, subscriber, or patient portion of the file on which errors were found.
A/B MACs and DME MACs, or their shared systems, shall use all information supplied in the BCRC Detailed Error Report (particularly error source codes provided in Field 10 of Attachment B) to (1) identify shared system changes necessary to prevent future errors in test mode or production mode (Test/Production Indicator= T or P) and (2) to notify physicians, suppliers, and providers that claims with the error source codes '111,' '222,' and '333' will not be crossed over to the COBA trading partner.
A/B MACs and DME MACs, or their shared systems, shall provide notification to MAC financial management staff for purposes of maintaining an effective reconciliation of crossover fee/ complementary credits received within five (5) business days of receipt of the BCRC Detailed Error Report.
Effective with the October 2005 release, A/B MACs and DME MACs and their shared systems shall receive BCRC Detailed Error Reports that contain BHT03 identifiers that indicate 'T' (test) or 'P' (production) status for purposes of fulfilling the provider notification requirements. (Note: The 'T' or the P' portion of
the BHT03 indicator will be identical to the Test/Production indicator originally returned from CWF on the processed claim.)
a) Special Automated Provider Correspondence
A/B MACs and DME MACs, or their shared systems, shall also take the following actions indicated below only when they determine via the Beneficiary Other Insurance (BOI) reply trailer (29) that a COBA trading partner is in crossover production mode with the BCRC (Test/Production Indicator=P). After an A/B MAC or DME MAC, or its shared system, has received a BCRC Detailed Error Report that contains claims with error source codes of “111” (flat file error), “222” (HIPAA ASC X12 error), or “333” (trading partner dispute), it shall take the following two specified actions within five (5) business days:
1. Notify the physician/practitioner, supplier, or provider via automated letter or other electronic or automated method that the claim did not cross over. The letter or report/notification shall include specific claim information, not limited to, Internal Control Number (ICN)/Document Control Number (DCN), Medicare beneficiary identifier, Medical Record Number (for Part A only), Patient Control Number (only if it is contained in the claim), beneficiary name, date of service, and the date claim was processed.
2. Effective with July 2007, A/B MACs and DME MACs and their systems shall ensure that, in addition to the standard letter language (the claim(s) was/were not crossed over due to claim data errors and was/were rejected by the supplemental insurer), their A/B MACs’ and DME MACs’ special provider letters or reports/notifications, which are generated for ‘222’ and ‘333’ error rejections in accordance with CR 4277, now include the following additional elements, as derived from the BCRC Detailed Error Report: 1) HIPAA H-series rejection code or other rejection code, and 2) the rejection code’s accompanying description.
NOTE: A/B MACs or DME MACs, or their shared systems, are not required to reference the COBA trading partner’s name on the above described automated letter or report/notification, since the original remittance advice (RA)/electronic remittance advice (ERA) would have listed that information, if appropriate.
2. Update its claims history to reflect that the claim(s) did not cross over as a result of the generation of the automated letter or report.
Effective with October 1, 2007, all A/B MACs and DME MACs shall modify their special provider notification letters that are generated for “111,” “222,” and “333” error situations to include the following standard language within the opening paragraph of their letters or reports: “This claim(s) was/were not crossed over due to claim data errors or was/were rejected by the supplemental insurer.”
A/B MACs and DME MACs shall reformat their provider notification letters or reports to ensure that, in addition to the new standard letter language, they continue to include the rejection code and accompanying description, as derived from the BCRC Detailed Error Report, for “222” or “333” errors in association with each errored claim.
Effective with the July 7, 2009, release, upon receipt of the BCRC Detailed Error Report (DER), the A/B MAC (A) and A/B MAC (HH) shared system shall configure the existing 114 report, as derived from the BCRC DER, so that it: 1) continues to display in landscape format; and 2) includes a cover page that contains the provider’s correspondence mailing address.
b) Special Exemption from Generating Provider Notification Letters/Reports
Effective July 7, 2008, upon their receipt of BCRC Detailed Error Reports that contain “222” error codes 000100 (“Claim is contained within a BHT envelope previously crossed; claim rejected”) and 00010 (“Duplicate claim; duplicate ST-SE detected”), all shared systems shall automatically suppress generation of the special provider notification letters or reports/notifications that they would normally generate for their associated A/B MACs and DME MACs in accordance with the requirements of this section as well as §70.6.3 of this chapter. In addition, upon receipt of BCRC Detailed Error Reports that contain “333” (trading partner dispute) error code 000100 (duplicate claim) or 000110 (duplicate ISA-IEA) or 000120 (duplicate ST-SE), all shared systems shall automatically suppress generation of the special provider notification letters or reports/notifications, as would normally be required in accordance with this section as well as §70.6.3 of this chapter.
NOTE: When suppressing their provider notification letters or reports/notifications for the foregoing qualified situations, the A/B MACs and DME MACs shall also not update their claims histories to reflect the non-crossing over of the associated claims. A/B MACs and DME MACs should, however, continue to account for the volume of claims that they are suppressing for financial reconciliation purposes.
Effective with October 6, 2008, when the BCRC returns the “222” error code “N22225” to A/B MACs and DME MACs via the BCRC Detailed Error Report, the A/B MACs and DME MACs’ shared systems shall suppress generation of the special provider notification letters or reports/notifications that they would normally issue in accordance with CRs 3709 and 5472.
When suppressing their provider notification letters or reports/notifications following their receipt of a “N22225” error code, the A/B MACs’ and DME MACs’ shared systems shall also not update their claims histories to reflect the non-crossing over of the associated claims. A/B MACs and DME MACs should, however, continue to account for the volume of claims that they are suppressing for financial reconciliation purposes.
Effective with January 5, 2009, when the BCRC returns claims on the BCRC Detailed Error Report whose COBA ID falls in the range 89000 through 89999 (range designates “Other-Health Care Pre-payment Plan [HCPP] and HMO Cost Plan”), the A/B MACs’ and DME MACs’ systems shall take the following actions:
1) Suppress generation of the special provider letters or reports/notifications; and
2) Not update their affiliated A/B MACs and DME MACs’ claims histories to indicate that the BCRC will not be crossing the affected claims over.
(Rev. 3714, Issued: 02-03-17; Effective: 07-01-17; Implementation: 07-03-17)
Effective with the implementation of the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 837 5010 COB requirements, the BCRC will return the error codes shown in the chart below to all A/B MACs and DME MACs whose flat file submissions lack structural elements necessary for the building of outbound HIPAA compliant crossover claims.
The shared systems shall, in addition, make modifications to any “111” error tables that they maintain, in accordance with the following charts, only in association with ASC X12 837 5010 COB flat files.
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 100 | No ST Segment | NO | NO | NO | NO | NO | YES | NO | NO | NO | HEAD |
| 101 | No BHT Segment | YES | NO | NO | NO | NO | YES | NO | NO | NO | HEAD |
| 103 | Missing 1000A Records | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 104 | Missing 1000B Records | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 105 | Invalid 1000A.NM109 | YES | NO | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 110 | Invalid 1000B.NM103 | YES | NO | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 115 | Invalid 1000B.NM109 | YES | YES | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 120 | Multiple 1000A per ST/SE | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 125 | Multiple 1000B per ST/SE | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 199 | All 2000B Rejected | YES | YES | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 200 | Missing 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 201 | Missing 2010AA | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 210 | Multiple 2010AA per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 211 | Multiple 2010AB per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 212 | Invalid presence of 2010AC per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 300 | Missing 2000B | YES | YES | NO | NO | YES | YES | NO | NO | YES | SUB |
| 301 | Missing 2010BA | YES | YES | NO | NO | YES | YES | NO | NO | YES | SUB |
| 302 | Missing 2010BB Loop | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 305 | Multiple 2010BB per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 306 | Multiple 2010BA per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 310 | 2010BB.NM109 not equal 1000B.NM109 | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 320 | 2010BB.N3 not equal spaces | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| 321 | 2010BB.N4 not equal spaces | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| 351 | More than 100 2300 per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 355 | 2300 REF01 Equal F5 Missing | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 356 | 2300 HI Invalid | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 399 | All 2300 Loops Rejected | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 400 | 2010CA Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | |
| 500 | 2300 Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 505 | 2320 Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 506 | # of 2320 Loops GT 10 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 507 | 2320 OI Not Found | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 515 | 2400 Not Found | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 520 | # of 2400 Loops GT 999 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 575 | 2330A Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 576 | 2330B Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 580 | 2320.SBR01 not equal P (must be at least one 'P' segment) | YES | YES | YES | NO | YES | YES | YES | YES | YES | CLM |
| 581 | 2320.SBR Field Invalid (SBR09 does not equal MB when Medicare is primary in SBR01) | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 590 | Multiple 2330A | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 591 | Multiple 2330B | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 595 | 2330B.REF02 Equal | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 596 | 2330B.NM109 Invalid COBA ID (Not Used) | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 597 | 2330B REF not found | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 598 | 2330B NM103 equals spaces and invalid COBA ID in 2330B NM109 | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 610 | # of 2430 Loops greater than 15 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 620 | 2430.SVD01 not equal 1000A.NM109 | YES | YES | YES | YES | YES | YES | YES | NO | YES | CLM |
| 999 | SE Segment Missing | YES | YES | NO | NO | NO | YES | NO | NO | YES | HEAD |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 100 | No ST Segment | NO | NO | NO | NO | NO | YES | NO | NO | NO | HEAD |
| 101 | No BHT Segment | YES | NO | NO | NO | NO | YES | NO | NO | NO | HEAD |
| 103 | Missing 1000A Records | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 104 | Missing 1000B Records | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 105 | Invalid 1000A.NM109 | YES | NO | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 110 | Invalid 1000B.NM103 | YES | NO | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 115 | Invalid 1000B.NM109 | YES | YES | NO | NO | YES | YES | YES | YES | YES | HEAD |
| 120 | Multiple 1000A per ST/SE | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 125 | Multiple 1000B per ST/SE | YES | NO | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 199 | All 2000B Rejected | YES | YES | NO | NO | YES | YES | NO | NO | YES | HEAD |
| 200 | Missing 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 201 | Missing 2010AA | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 210 | Multiple 2010AA per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 211 | Multiple 2010AB per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 212 | Invalid presence of 2010AC per 2000A | YES | YES | NO | NO | YES | YES | NO | NO | YES | PROV |
| 300 | Missing 2000B | YES | YES | NO | NO | YES | YES | NO | NO | YES | SUB |
| 301 | Missing 2010BA | YES | YES | NO | NO | YES | YES | NO | NO | YES | SUB |
| 302 | Missing 2010BB Loop | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 305 | Multiple 2010BB per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 306 | Multiple 2010BA per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 310 | 2010BB.NM109 not equal 1000B.NM109 | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| 320 | 2010BB.N3 not equal spaces | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 321 | 2010BB.N4 not equal spaces | YES | YES | YES | NO | YES | YES | YES | YES | YES | SUB |
| 351 | More than 100 2300 per 2000B | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 355 | 2300 REF01 Equal F5 Missing | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 356 | 2300 HI Invalid | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 399 | All 2300 Loops Rejected | YES | YES | YES | NO | YES | YES | NO | NO | YES | SUB |
| 400 | 2010CA Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | |
| 500 | 2300 Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 505 | 2320 Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 506 | # of 2320 Loops GT 10 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 507 | 2320 OI Not Found | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 515 | 2400 Not Found | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 520 | # of 2400 Loops GT 50 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 575 | 2330A Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 576 | 2330B Not Found | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 580 | 2320.SBR01 not Equal P (must be at least one “P” segment) | YES | YES | YES | NO | YES | YES | YES | YES | YES | CLM |
| 581 | 2320.SBR Field Invalid (SBR09 does not equal MB when Medicare is primary in SBR01) | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 590 | Multiple 2330A | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 591 | Multiple 2330B | YES | YES | YES | NO | YES | YES | NO | NO | YES | CLM |
| 595 | 2330B.REF02 Equal | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 596 | 2330B.NM109 Invalid COBA ID (Not Used) | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 597 | 2330B REF not found | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| 598 | 2330B NM103 equals spaces and invalid COBA ID in 2330B NM109 | YES | YES | YES | YES | YES | YES | YES | YES | YES | CLM |
| Error Code | Error Description | Control # | COBA ID | Medicare ID | CCN | Loop ID | Segment | Element | Content | BHT 03 | Reject Level |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 610 | # of 2430 Loops greater than 15 | YES | YES | YES | YES | YES | YES | NO | NO | YES | CLM |
| 620 | 2430.SVD01 not equal 1000A.NM109 | YES | YES | YES | YES | YES | YES | YES | NO | YES | CLM |
| 999 | SE Segment Missing | YES | YES | NO | NO | NO | YES | NO | NO | YES | HEAD |
(Rev. 4069, Issued: 06-08-18, Effective: 07-09- 8, Implementation: 07-09-18)
Effective with the July 2006 release, CMS implemented a full claim file repair process at its A/B MACs and DME MACs to address situations where one or more of the MAC shared systems inadvertently introduced a severe error condition into the claims processing cycle, with the effect being that the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 837 Coordination of Benefits (COB) Institutional and Professional crossover claims files or National Council for Prescription Drug Programs (NCPDP) claim files become unusable for COB purposes.
When an A/B MAC or DME MAC, the BCRC, or a COBA trading partner identifies a shared system problem that will prevent, or has prevented, the COBA trading partner from accepting an ASC X12 837 COB institutional or professional claims file from the BCRC, the A/B MAC and DME MAC shall work with its shared system maintainer to assess the feasibility of executing a full claim file repair. A/B MACs and DME MACs shall utilize the BCRC Detailed Error Reports to determine the percentage of errors present for each error source code—“111” (flat file) errors, “222” (ASC X12 837 COB) errors, and “333” (trading partner dispute) errors. When A/B MACs and DME MACs or their shared system maintainers determine that the error percentages are at or above the parameters discussed later within this section, the A/B MACs and DME MACs shall begin the process of analyzing the claim files for a possible full claim repair process. If the A/B MACs and DME MACs and their shared systems subsequently initiate a full claim file repair process, that process shall be accomplished within a maximum of 14 work days, unless determined otherwise by CMS.
Effective July 2, 2007, A/B MACs and DME MACs and their systems shall now base their decision making calculus for initiation of a claims repair of “111” (flat file) errors upon the number of errors received rather than upon an established percent parameter, as specified in §70.6.1 of this chapter. If an A/B MAC or DME MAC receives even one (1) “111” error via the BCRC Detailed Error Report, the MAC, working with its Data Center or shared system as necessary, shall immediately attempt a repair of the claims file, in accordance with all other requirements communicated within this section.
When an A/B MAC or DME MAC, working with its shared system maintainer, identifies a severe error condition that will negatively impact the claims that it has transmitted to the BCRC, the A/ B MAC or DME MAC shall, upon detection, immediately notify CMS and the BCRC by calling current BCRC or CMS COBA crossover contacts and sending e-mail communications to: COBAProcess@cms.hhs.gov and cobva@ghimedicare.com.
The A/B MAC or DME MAC shall work closely with its system maintainer to determine the timeframes for developing, testing, and applying a fix to correct the severe error(s) that was/were identified within the 837 or NCPDP files that were previously transmitted to the BCRC. The A/B MAC and DME MAC shared system maintainers shall then report the timeframes for developing, testing, and applying a fix to the full claim file problem in accordance with their procedures as outlined in their systems maintenance contract. If CMS determines that the time frames for affecting a full claim file repair of the previously transmitted claims exceed what is considered reasonable (a maximum of 14 work days, unless determined otherwise by CMS), a designated COBA team representative will notify the A/B MACs and DME MACs and their shared system maintainers via e-mail to abort the full claim file repair process. (NOTE: This process will remain unchanged with the transition to future claim versions.)
Upon receipt of a notification from the CMS COBA team representative that indicates that the timeframes for fixing a full claim file problem exceed those that are acceptable to CMS, the A/B MACs’ and DME MACs’ shared systems shall abort the full claim file repair process. A/B MACs and DME MACs shall then
follow the requirements provided in §70.6.1 of this chapter with respect to the special provider notification and other COBA crossover operational processes. In such cases, however, A/B MACs and DME MACs shall not be required to wait the customary five (5) business days before generating the special provider notification letters to their affected physicians, suppliers, or other providers of service.
Effective with July 2006, the CMS, working in conjunction with the BCRC, modified the BCRC Detailed Error Report layouts, as found in §70.6.1 of this chapter, to include the following new elements: Total Number of Claims for Date of Receipt; Total Number of “111” (flat file) Errors and corresponding percentage; Total Number of “222” (HIPAA ASC X12 837 COB) Errors and corresponding percentage; and Total Number of “333” (trading partner dispute) Errors and corresponding percentage.
Effective with July 2007, CMS directed its A/B MACs and DME MACs to now base their severe error decision calculus upon the number of “111” errors received rather than percentage of such errors. Therefore, when an A/B MAC or DME MAC or its shared system maintainer receives a BCRC Detailed Error Report that indicates that the trading partner is in production and the number of “111” (flat file) errors is equal to or greater than one, the A/ B MAC’s and DME MAC’s shared system shall suppress the generation of special provider notifications, as provided in § 70.6.1 of this chapter, until after the severe error condition(s) has/have been analyzed. (NOTE: If the “222” and/or “333” errors indicated on the BCRC Detailed Error Report do not exceed the four (4) percent parameter, then the A/B MAC and DME MAC shall continue with the generation of the provider notification letters for those errors while it is analyzing the “111” severe error(s).)
IMPORTANT: Effective October 1, 2007, A/B MACs and DME MACs and their systems shall have the capability to initiate a claims repair process, internally or at CMS direction, for situations in which they encounter high volume “222” or “333” error rejections that do not meet or exceed the established error threshold parameters. Before initiating a claims repair for error situations that fall below the established percentage parameters, the affected A/B MACs and DME MACs shall first contact a member of the CMS COBA team to obtain clearance for that process.
When an A/B MAC or DME MAC or its shared system maintainer receives a BCRC Detailed Error Report that indicates that the trading partner is in production and the percentage of “222” (HIPAA ASC X12 837) errors and “333” (trading partner dispute) errors is equal to or greater than four (4) percent, the shared system shall suppress the generation of special provider notifications, as provided in §70.6.1 of this chapter, until after the severe error condition(s) has/have been analyzed. NOTE: If the number of “111” errors indicated on the BCRC Detailed Error Report is not equal to or greater than one (1), then the A/B MAC or DME MAC shall continue with the generation of the provider notification letters for those errors while it is analyzing the “222” and “333” severe errors.
For each of the severe error situations discussed above, A/B MACs and DME MACs, or their shared systems, shall suppress the special provider notification for a minimum of five (5) business days. The shared systems shall also have the capability to adjust the parameters for generation of the provider notification letters, as referenced in §70.6.1 of this chapter, of up to 14 work days while analysis of the claims that are being “held” for possible full claim file repair is proceeding.
Effective October 1, 2007, all A/B MACs and DME MACs shall have the capability to suppress their provider notification letters for a timeframe of up to 14 work days, or longer at CMS direction, where they initiate a claims repair process when claims with “222” or “333” errors fall below the “normally established” four (4) percent threshold.
Also, for each of the situations discussed above, the A/B MACs and DME MACs' shared systems shall establish percentage parameters for each error source code (222 and 333) that allow for flexibility within a range (e.g., 1 to 10 percent).
b. Additional Information Highlighting Possible Severe Error Conditions on the BCRC Detailed Error Reports.
Effective with July 2006, the BCRC will report one of the following error sources and error codes/trading partner dispute codes that may be indicative of a severe error condition on the returned BCRC Institutional and Professional Detailed Error Reports:
1.) Error source code "111" will be reported in field 10, along with a 6-digit error code in field 11 (note: unlike routine reporting of flat file errors, a full claim file error condition would be indicated if there were numerous instances of the same error code repeated throughout a Report); the description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 12 (error description);
2.) Error source code "222" will be reported in field 10, along with a 6-digit error code in field 11 that begins with an "N"; the description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 12 (error description);
3.) Error source code "333" will be reported in field 10; an error/trading partner dispute code "999" (trading partner dispute—"other") will be reported in field 11, left-justified and followed by spaces; and a description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 12 (error description).
DME MACs and their shared systems shall process NCPDP Detailed Error Reports returned from the BCRC that contain the following combination of error source codes, error/trading partner dispute codes, and error descriptions within the Reports:
1.) Error source code "111" will be reported in field 9, along with a 6-digit error code in field 10 (NOTE: Unlike routine reporting of flat file errors, a full claim file error condition would be indicated if there were numerous instances of the same error code repeated throughout a Report); and a description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 11; or
2.) Error source code "333" will be reported in field 9; an error/trading partner dispute code "999" will be reported in field 10, left-justified and followed by spaces; and a description of the problem(s) that has/have caused the full claim file to be unusable will be reported in field 11 (error description).
c. A/B MAC and DME MAC Actions Following Suppression of the Special Provider Notification Letters to Analyze Possible Severe Error Conditions
When A/B MACs and DME MACs receive BCRC Detailed Error Reports that contain "222" or "333" errors with percentages that are at or above the established parameters—or if the MACs receive "111" errors that are at or above zero ("0")—they shall work closely with their shared system maintainers to determine the timeframes for developing, testing, and applying a fix to correct the severe error(s) that was/were identified within the ASC X12 837 or NCPDP files that were previously transmitted to the BCRC. The shared system maintainers shall then report the timeframes for developing, testing, and applying a fix to the full claim file problem in accordance with their procedures as outlined in their systems maintenance contract. If CMS determines that the timeframes for affecting a full claim file repair of the previously transmitted claims exceed what is considered reasonable (a maximum of 14
work days, unless determined otherwise by CMS), a designated COBA team representative will notify the A/B MACs and DME MACs and their shared system maintainers via e-mail to abort the full claim file repair process.
As noted above, effective October 1, 2007, all A/B MACs and DME MACs shall have the capability to suppress their provider notification letters for a timeframe of up to 14 work days, or longer at CMS direction, where they initiate a claims repair process when claims with “222” or “333” errors fall below the “normally established” four (4) percent threshold.
Upon receipt of a notification from the CMS COBA team representative that indicates that the timeframes for fixing a full claim file problem exceed those that are acceptable to CMS, the A/B MACs and DME MACs’ shared systems shall abort the full claim file repair process. A/B MACs and DME MACs shall then follow the requirements provided in §70.6.1 of this chapter with respect to the special provider notification and other COBA crossover operational processes. In such cases, however, A/B MACs and DME MACs shall not be required to wait the customary five (5) business days before generating the special provider notification letters to their affected physicians/practitioners, suppliers, or other providers of service.
In the event that CMS indicates that a full claim file repair process is feasible, the A/B MACs and DME MACs’ shared systems shall have the ability to cancel the generation of the provider notification letters, as stipulated in §70.6.1 of this chapter, for the “repaired” claims and only generate the provider notification letters for the claims containing legitimate 111, 222, or 333 errors not connected with the severe error condition(s).
Once the A/B MACs and DME MACs’ shared systems have determined that they are able to affect a “timely” repair to the full claim files that were previously transmitted to the BCRC, they shall take the following actions:
a) Apply the fix to the unusable claims;
b) Compare the claims files previously sent to the BCRC with the repaired claims file to isolate the claims that previously did not contain the error condition(s);
c) Strip off the claims that did not contain the error condition(s), including claims that contained 111, 222, and 333 errors that were not connected with the severe error condition(s). For the latter set of claims (those with 111, 222, and 333 errors that were not connected to the severe error condition), MACs shall then generate the provider notification letters, as stipulated in §70.6.1 of this chapter and specified in the concluding paragraph of the above sub-section entitled, “Contractor Actions Following Suppression of the Special Provider Notification Letters to Analyze Possible Severe Error Conditions”;
d) Recreate the job; and
e) Send only the “repaired” claims to the BCRC.
The shared systems shall add an indicator “18” to the BHT02 (Beginning of the Hierarchical Transaction/Transaction Set Purpose Code) segment of the HIPAA ASC X12 837 flat file to designate that the file contains only repaired claims. In addition, the shared systems shall include the repaired claims in different ST-SE envelopes to differentiate the repaired claims from normal ASC X12 837 flat file transmissions.
The DME MAC shared system shall add an indicator “R” after the COBA ID reported in the Batch Header Record in the Receiver ID field (field number 880-K7) of the NCPDP claim when transmitting the repaired claims to the BCRC.
All A/B MACs and DME MACs shall effectuate repair of even one “111” errored COB claim if the COBA trading partner is currently in “production” mode. (NOTE: Parties interested in previewing a listing of all “111” errors that the BCRC will apply to incoming COB flat files should refer to §70.6.1.1 of this chapter.) The shared systems shall accept the “111” error codes (see §70.6.1.1 of this chapter) that the BCRC generates during its application of business level editing to incoming ASC X12 837 COB flat files. The shared systems shall also make modifications to any “111” error tables that they maintain only in association with ASC X12 837 COB flat files.
IMPORTANT: A/B MACs and DME MACs shall only issue special provider notification letters in association with their receipt of “111” errors if: 1) the timeframe for effectuating a claims repair falls outside acceptable parameters (e.g., will take 30-60 days or longer); and 2) the volume of affected claims is low (i.e., under 1,000 claims per week). A/B MAC and DME MAC crossover contacts should contact a member of the CMS COBA team if they have questions regarding how they should proceed in association with a given “111” error situation.
A/B MACs and DME MACs and their shared systems shall repair “222” or “333” errors in association with “production” new format version claims if the error percentage they encounter meets or exceeds four (4) percent.
A/B MACs and DME MACs shall alert their shared system or Data Center, as per established protocol, for purposes of initiating each needed claims repair process in association with new format version COB claims. IMPORTANT: A/B MACs and DME MACs that wish to effectuate a repair of new format version “production” claims whose error percentage falls below four (4) percent shall contact a member of the CMS COBA team before attempting that action. (NOTE: As a rule, CMS will grant approval for such a repair if the volume of errored claims justifies that action and if the timeframe for repair is acceptable.)
In accordance with §70.6.1 of this chapter, A/B MACs and DME MACs shall issue special provider notification letters in those instances where 1) error percentages for “222” and “333” errors fall below four (4) percent; 2) the volume of errors on “production” new format version COB is not substantial enough to cause the A/B MAC or DME MAC to request a claims repair; or 3) the timeframes for claim repair, as determined by the associated shared system, are not acceptable to CMS.
While A/B MACs and DME MACs are not expected to initiate the repair of “test” claims, they shall: 1) continue to monitor the BCRC Detailed Error Reports; and 2) notify their shared systems of errors returned so that necessary shared system changes to improve HIPAA compliance rates may be realized.
To ensure appropriate cutover to the HIPAA ASC X12 COB flat file format, all shared systems shall develop new date parameter logic to become operational as of January 1, 2012. All shared systems shall ensure that the new logic addresses all of the following scenarios: repairing any errored old format claims in the current claim format; converting claims held in suspense from an old format to the current claim format;
converting previously adjudicated old format claims to the current 'skinny' non-SFR COB claim format in adjustment claim situations; and converting claims held in 'provider alert status' from an earlier) format to the current 'skinny' non-SFR COB claim format.
For claims repair scenarios involving claims previously sent to the BCRC in the prior format just prior to January 1, 2012, the shared systems shall retransmit repaired claims to the BCRC in the current format. To that end, all shared systems shall utilize CMS-issued mapping and gap-filling guidance provided in chapter 24 §40.4 and chapter 28 §70.6.5 of Pub.100-04 when repairing their originally transmitted prior format errored crossover claims in the HIPAA current ASC X12 837 claim format on and after January 1, 2012. In addition, the shared systems shall apply current non-SFR 'skinny' logic to claim repair situations where they originally transmitted claims to the BCRC prior to January 1, 2012 in the prior claim format.
IMPORTANT: A/B MACs and DME MACs shall not repair errored claims in a prior format that they transmitted to the BCRC just prior to January 1, 2012 if the errors returned via the BCRC Detailed Error Report relate to a field or segment that no longer exists in the current claim format. Instead, A/B MACs and DME MACs shall issue provider notification letters for those errored claims to the affected providers.
(Rev. 10638; Issued: 03-09-21; Effective: 04-05-21; Implementation: 04-05-21)
Effective January 2, 2007, when the CMS or the BCRC determines that 1) certain members on a COBA production trading partner's eligibility file were not properly loaded to the Common Working File (CWF) Beneficiary Other Insurance (BOI) auxiliary file (see §70.6 of this chapter for more details regarding this file) or 2) a COBA production trading partner's claims selections, as conveyed via the COBA Insurance File (COIF), were not properly loaded to the CWF, the CMS shall send the A/B MAC crossover contact(s) and associated Virtual Data Center (VDC) a 'COBAProcess' e-mail communication. When the CMS sends a 'COBAProcess' e-mail communication to an A/B MAC to initiate a COBA eligibility file claims recovery process, the A/ B MAC shall acknowledge receipt of the communication via return e-mail within 1 business day. The CMS will then contact the A/B MAC's crossover staff and associated VDC either via phone or e-mail to discuss the specific Common Working File (CWF) date span (i.e., process date) or claim date of service parameters, or both, for the claims recovery process. Additionally, CMS will specify which specific MAC(s), by state, will be involved in the COBA claims recovery activity. (NOTE: DME MACs and their shared system may be required to implement the COBA eligibility file claims recovery process as part of a future instruction.)
Following the telephone discussion between the CMS and the A/B MAC crossover staff, the COBA eligibility file recovery process will further unfold as detailed below.
Until April 5, 2021, as part of an active COBA claims recovery, the two VDCs that support the A/B MACs shall complete an Electronic Transmittal Form (See Attachment A at the conclusion of this section) on behalf of their associated MACs that are participating in a COBA claims recovery process. (Note: The COBA E01 eligibility file contains specifications on the COBA trading partner and the individuals whose claims need to be recovered.)
Effective April 5, 2021, the VDCs shall be prepared to accept the following modified dataset names for the COBA E01 Eligibility File as received from the CMS BDC:
Perspecta VDC Part A Recovery E01 Eligibility File: ASH0.FISP.HBADR.GHI.FSSFCOBE(+1)
Perspecta VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)
Companion Data Services (CDS) VDC Part A Recovery E01 Eligibility File: ASP2.FISP.NDM.FSSFCOBE(+1)
CDS VDC Part B Recovery E01 Eligibility File: B999.MCSP.HBXDR.AR99RCVR(+1)
Through the COBA claims recovery process, the COB&R system supporting the BCRC sends the appropriate VDC a copy of the trading partner's COBA eligibility file(s), which will be prepared in accordance with the CMS proprietary format. (Note: The COB&R system supporting the BCRC will transmit the COBA eligibility file to the VDC through its existing Connect: Direct connection.) The VDC then notifies the affected A/B MAC(s) that the COBA recovery eligibility file is available so that the A/B MAC(s) may initiate a claims recovery.
Effective April 1, 2019, the shared systems supporting the A/B MACs shall accept either a Health Insurance Claim Number (HICN) or Medicare Beneficiary Identifier (MBI), as reported via the COBA E01 eligibility file, in the field defined as "Beneficiary Medicare ID" (file displacement 64—75).
The A/B MAC shall initiate recovery of the processed claims by systematically going against its online claims history that meet the beneficiaries' eligibility dates, as provided on the BCRC eligibility file(s), and that fall within the specified CWF date span (i.e., process date) or date of service parameters, or both, that CMS has provided to the A/B MAC.
In performing the COBA claims recovery, MACs shall not attempt to recover claims that were previously transmitted to the BCRC. "Previously transmitted claims" may be identified by the claims' crossover location status or the presence of the COBA ID being used for the recovery process along with a "P" (production) indicator in association with the processed claims.
Additionally, the MAC shall not apply the COBA trading partner's selection criteria, as found on the Health Insurance Master Record (HIMR) COBS, when recovering claims.
The A/B MAC shall complete its claims recovery process, culminating with transmission of the recovered claims to the COB&R system supporting the BCRC, within eight (8) work days following the date that it receives the BCRC COBA eligibility file or as soon as possible thereafter as CMS directs.
A/ B MACs shall perform the following activities related to the COBA eligibility file:
a) Utilize each beneficiary's coverage dates from the COBA eligibility files (file displacement 121—128 for beneficiary supplemental eligibility-from date and file displacement 129—136 for beneficiary supplemental-to date); and successive eligibility-from and eligibility-to dates if provided);
b) Apply the specified CWF date span; or
c) Apply the date of service parameters; or
d) Both items b and c above.
Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B loop of the flat file containing the recovered Part A and B claims.
A/ B MACs shall perform the following activities related to the COBA eligibility file:
Once the A/B MAC, working with the VDC as necessary, has recovered the specified claims, it shall copy the COBA ID from the BCRC COBA eligibility file and place it within the NM109 segment of the 1000B loop of the flat file containing the recovered Part A and B claims.
Neither the A/B MAC nor its VDC shall be required to search archived claims history while fulfilling the COBA eligibility file claims recovery process.
The A/ B MAC and its VDC shall not be required to apply the COBA production trading partner's selection criteria before transmitting the recovered claims to the BCRC.
The A/B MAC or its VDC shall not transmit claims that had previously been sent to the BCRC as part of the COBA eligibility file claims recovery process, as demonstrated by the claims' crossover location status or the presence of a COBA identification (ID) number accompanied by a 'P' (production) indicator in relation to the processed claims.
The A/ B MAC shared systems shall be required to populate an 'R' indicator in the 22nd position of the Beginning of the Hierarchical Transaction (BHT)-03 segment of the ASC X12 837 flat file when transmitting recovered claims for COBA production trading partners to the BCRC. (NOTE: The CMS would only consider invoking the COBA eligibility file recovery process for trading partners that are in production mode. Therefore, this practice does not conflict with previous guidance issued by the CMS, which may be referenced in §70.6.1 of this chapter.)
The recovered claim files shall be prepared in the same ASC X12 837 flat file format used for normal, daily transmissions to the COB&R system in support of BCRC, as discussed in §70.6 of this chapter.
Effective April 5, 2021, in transmitting the recovered claims to the CMS BDC (which, in turn, transmits the files to the COB&R system in support of the BCRC), the VDCs shall transmit the claims via a separate ASC X12 837 flat file transmission using the modified EFT dataset names shown below.
Note the following definitions apply to the dataset names above:
The VDCs shall send no more than 100,000 recovered claims (which equates to 20 ST-SE envelopes per A/B MAC with 5,000 claims per envelope) to the COB&R system supporting the BCRC per transmission.
When the VDC transmits the recovered claims to the COB&R system supporting the BCRC, the A/B MAC shall mark its claims history to indicate that each claim was recovered and transmitted to the BCRC to be crossed over to the COBA trading partner.
A/B MACs shall notify their customer service representatives that they will be able to determine that recovered claims were sent to the BCRC by referencing claims history.
If A/B MACs receive BCRC Detailed Error Reports that contain a 22-byte BHT-03 identifier that ends with an ‘R,’ they shall suppress generation of provider letters, regardless of the error source code indicated (‘111,’ ‘222,’ or ‘333’).
When the A/B MAC, or its shared system, receives BCRC Detailed Error Reports for recovered BCRC Detailed Error Reports for recovered claims that contain ‘111,’ ‘222,’ or ‘333’ errors, it shall mark its claims history to indicate that the recovered claims will not be crossed over.
A/B MACs, and their shared systems, shall assume that recovered claims for COBA production trading partners that exceed established percentage parameters for ‘111,’ ‘222,’ and ‘333’ errors are potential candidates for the COBA repair process, as provided in §70.6.2 of this chapter.
In accordance with the full claim file repair process discussed in 70.6.2 of this chapter, A/B MACs and their shared systems shall populate an ‘18’ Beginning of the Hierarchical Transmission (BHT)-02 transaction set purpose code at the ST-SE envelope level when transmitting the ‘repaired’ COBA recovery claims.
Unlike the process documented in §70.6.2 of this chapter, A/B MACs shall transmit ‘repaired’ COBA recovery claims to the COB&R system supporting the BCRC via the separate ASC X12 837 flat file transmission for recovery claims, as described within “Preparation and Transmission Requirements” above.
In addition, unlike the existing full claim file recovery process documented in §70.6. 2 of this chapter, A/B MACs and their shared systems shall include an ‘R’ in the 22nd position of the BHT-03 identifier when transmitting the ‘repaired’ COBA recovery claims to the COB&R system supporting the BCRC.
A/B MACs, or their shared systems, shall also not generate provider notification letters if they, in conjunction with CMS, determine that the recovered claims that contained severe errors cannot be repaired.
The CMS will reimburse the A/B MAC for individual claims accepted by the trading partner at the current per claim rate.
The A/B MACs’ shared systems shall develop a separate report for their associated A/B MACs to enable them to fulfill the foregoing requirements. The shared systems shall create reports that will provide MACs with the count of recovered claims per cycle.
Special note: With the modernization of the Electronic Files Transfer (EFT) process used for COBA, the A/B MACs and their associated VDCs will no longer need to complete the Electronic Transmittal Form (Attachment) A, as included below, prior to initiating a COBA claims recovery process effective April 5, 2021.
Project: Coordination of Benefits Agreement (COBA)
Task: COBA Claims Recovery Process
Contact Information
Company Name: _______
Contact Name: ____ Phone# ___ ext. _
Contact Email Address: ___________
CMSNet Information
Account ID: ____ Node ID: ____
IP Address: ____ Port: ____
Production Requirements
Filename(s): ___________
Special Instructions (e.g., file triggers):
Test Requirements
Filename(s):
Special Instructions (e.g., file triggers):
Table 1: COBA Eligibility E01 Record Layout Header – E00
| Data Element | Description | Field Length | MO | Field Location |
|---|---|---|---|---|
| HEADER RECORD TYPE | Value -E00 | 3X | O | E00.001 |
| HEADER COBA ID | COBA ID assigned by the COBC Field is 9 position, alphanumeric (no special characters), left justified, last four positions are spaces. Mandatory. | 9X | O | E00.002 |
| HEADER CREATION DATE | Date the record was created; format: (CCYYMMDD), with no special characters | 8X | O | E00.003 |
| HEADER BENEFICIARY STATE CODE | Beneficiary State of residence NOTE: This field will not be used by the COBA Process. | 2X | O | E00.004 |
| FILLER | Blank Field. Value is spaces. | 178X | O | E00.005 |
Table 2: COBA Eligibility E01 Record Layout
File attributes:
Format: Fixed block
Length: 200 bytes
| Data Field | Length | Type | Displacement | Description |
|---|---|---|---|---|
| Record type | 3 | Alpha-Numeric | 1–3 | Type of Record Set to 'E01'. Mandatory |
| COBA ID | 9 | Alpha-Numeric | 4-12 | Coordination of Benefits Agreement Identification Number Field is 9 position, alphanumeric (no special characters), left justified, last four positions are spaces. Mandatory |
| File Effective Date | 8 | Alpha-Numeric | 13-20 | Effective date of file in CCYYMMDD format with no special characters. Mandatory |
| Data Field | Length | Type | Displacement | Description |
|---|---|---|---|---|
| File Update Indicator | 1 | Alpha-Numeric | 21 | Type of update values: 'A' = Add 'C' = Change/Update 'D' = Delete Required as of March 1, 2007 |
| *Beneficiary Surname | 20 | Alpha-Numeric | 22-41 | Beneficiary last name Mandatory Uppercase characters only |
| *Beneficiary First | 12 | Alpha-Numeric | 42-53 | Beneficiary first name. Mandatory Uppercase characters only |
| Beneficiary Middle Initial | 1 | Alpha-Numeric | 54 | Beneficiary middle initial. Optional Uppercase characters only |
| *Beneficiary Birth Date | 8 | Alpha-Numeric | 55-62 | Beneficiary date of birth in CCYYMMDD format with no special characters. Mandatory |
| *Beneficiary Sex Code | 1 | Alpha-Numeric | 63 | Beneficiary sex code values are: 'M' = Male 'F' = Female NOTE: If unknown, default to 'M' Mandatory Uppercase characters only |
| Beneficiary Medicare ID | 12 | Alpha-Numeric | 64-75 | Beneficiary Medicare ID (Medicare Health Insurance Claim Number [HICN] or Medicare Beneficiary Identifier [MBI]). Mandatory |
| Beneficiary Supplemental ID Number | 25 | Alpha-Numeric | 76-100 | Supplemental ID on file with sender. Should be the same as what is submitted on the claim. Optional |
| Beneficiary Group Policy Number | 20 | Alpha-Numeric | 101-120 | Supplemental policy number on file. Should be the same as what is submitted on the claim. Optional |
| Beneficiary Supplemental Eligibility From Date-1 | 8 | Alpha-Numeric | 121-128 | Medicare supplemental 'from' date in CCYYMMDD format with no special characters. Mandatory |
|---|---|---|---|---|
| Data Field | Length | Type | Displacement | Description |
|---|---|---|---|---|
| Beneficiary Supplemental Eligibility To Date-1 | 8 | Alpha-Numeric | 129-136 | Medicare supplemental 'to' date in CCYYMMDD format with no special characters NOTE: This is the coverage through date. Indicate zeros for open-ended dates. Mandatory |
| Filler | 64 | Alpha- Numeric | 137-200 | Unused Field – Populate with spaces |
Table 3: COBA Eligibility E01 Record Layout Trailer Record – E99
| Data Element | Description | Field Length | MO | Field Location |
|---|---|---|---|---|
| Record Type | Value is 'E99'. | 3X | M | E99.001 |
| E01 Record Count | Total number of E01 records in this file. | 7N | M | E99.002 |
| Filler | Blank Field – Value is spaces | 190X | M | E99.003 |
Coordination of Benefits (COB) Mapping Requirements as of July 2012 (Rev. 4281, Issued: 04- 19-19, Effective: 05-20-19, Implementation: 05-20-19)
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.
During the ASC X12 837 transitional period, the shared systems shall accommodate the multi-faceted scenarios that follow below each broad category with respect to creation of ASC X12 837 COB flat files.
Scenario 1: During the ASC X12 837 future version transitional period, if a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837 future version institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a Common Working File (CWF) Beneficiary Other Insurance (BOI) reply trailer (29) that contains a 'P' current, in use version Test/Production indicator and a 'T' future version indicator, the affected shared systems shall: 1) produce a 'skinny' non-SFR 'production' claim in the current, in use version ASC X12 837 COB flat file for transmission to the BCRC; and 2) produce an ASC X12 837 future version 'test' COB flat file that contains a claim with full SFR content for transmission to the BCRC.
Scenario 2: If a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837 future version institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains a 'P' current, in use version Test/Production indicator and an 'N' future version indicator, the affected shared systems shall: 1) produce a 'skinny' non-SFR 'production' claim in the ASC X12 current, in use version 837 COB flat file for transmission to the BCRC; and 2) produce nothing in terms of an ASC X12 837 future version COB flat file.
Scenario 3: If a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837 future version institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an 'N' current, in use version Test/Production indicator and a 'T' future version indicator, the affected shared system shall: 1) produce nothing in terms of a current version ASC X12 837 COB flat
file; and 2) produce a future version “test” claim with full SFR content for COBA testing purposes.
Scenario 4: If a provider, physician/practitioner, or supplier submits a HIPAA ASC X12 837 future version institutional or professional claim to an A/B MAC or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an “N” current, in use version Test/Production indicator and a “P” future version indicator, the affected shared system shall: 1) produce nothing in terms of a current, in use version ASC X12 837 COB flat file; and 2) produce a “production” future version claim with full SFR content for COBA “production” purposes.
(NOTE: Scenario 4 will be the profile of a COBA trading partner that has cut-over to the future version ASC X12 837 COB production.)
Scenario 1: During the transitional period, if a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains a “P” current version Test/Production indicator and a “T” future version indicator, the affected shared systems shall: 1) create an 837 COB flat file that contains full current version SFR content for the “production” claim for transmission to the BCRC; and 2) create a “skinny” non-SFR claim in the future version ASC X12 837 COB flat file format for the “test” future version claim and transmit the file to the BCRC.
Scenario 2: If a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or DME MAC, as appropriate, and if that entity receives a CWF BOI reply trailer (29) that contains a “P” current version Test/Production indicator and an “N” future version indicator, the affected shared systems shall: 1) create an 837 COB flat file that contains full current version SFR content for the “production” claim; and 2) create nothing in terms of a future version COB claim.
Scenario 3: If a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an “N” current version Test/Production indicator and a “T” future version indicator, the affected shared systems shall: 1) create nothing in terms of a current use version COB claim; and 2) create a “test” future version non-SFR COB claim.
Scenario 4: If a provider, physician/practitioner, or supplier submits an ASC X12 837 current version institutional or professional claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a Common Working File (CWF) Beneficiary Other Insurance (BOI) reply trailer (29) that contains an “N” current version
Test/Production indicator and a “P” future version indicator, the affected shared systems shall: 1) create nothing in terms of a current version COB claim; and 2) create a “production” future version non-SFR COB claim.
The shared system shall produce a future version “skinny” claim, without SFR content, in the event that a claim that an A/B MAC or DME MAC originally adjudicated in the current version format is later released from suspense status or is adjusted during a time frame when a COBA trading partner has moved to the ASC X12 837 future version production (that is, the BOI reply trailer 29 contains a “P” future version Test/Production indicator).
In addition, as of the mandatory cutover date to the future version claim transaction, all shared systems shall have the capability of repairing claims that previously erred out in the current version format prior to the cutover date, doing so in the future version COB claim format on and after January 1, 2012.
Scenario 1: During the transitional period, if a provider, physician/practitioner, or supplier submits a hard-copy claim (paper Form CMS-1450 or Form CMS-1500) or, as applicable, enters a direct-data-entry (DDE) claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains a “P” current version Test/Production indicator and a “T” future version indicator, the affected shared system shall: 1) produce a “skinny” non-SFR current version “production” COB claim; and 2) produce a “skinny” non-SFR future version “test” COB claim.
Scenario 2: If a provider, physician/practitioner, or supplier submits a hard-copy claim (paper Form CMS-1450 or Form CMS-1500) or, as applicable, enters a DDE claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains a “P” current version Test/Production indicator and an “N” future version indicator, the affected shared system shall: 1) produce a “skinny” non-SFR current version “production” COB claim; and 2) produce nothing in terms of a future version COB claim.
Scenario 3: If a provider, physician/practitioner, or supplier submits a hard-copy claim (paper Form CMS-1450 or Form CMS-1500) or, as applicable, enters a DDE claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity receives a CWF BOI reply trailer (29) that contains an “N” current version Test/Production indicator and a “T” future version indicator, the affected shared system shall: 1) produce nothing in terms of a current version claim; and 2) produce a “skinny” non-SFR future version “test” COB claim.
Scenario 4: Finally, if a provider, physician/practitioner, or supplier submits a hard-copy claim (paper Form CMS-1450 or Form CMS-1500) or, as applicable, enters a DDE claim to an A/B MAC (A), A/B MAC (HH), or DME MAC and if that entity a CWF BOI reply trailer (29) that contains an “N” current version Test/Production indicator and a “P” future version indicator, the affected shared system shall: 1) produce nothing in terms of a current version COB claim; and 2) produce a “skinny” non-SFR future version “production” COB claim.
IMPORTANT: For all scenarios, if the inbound claim’s format is the same as the outbound claim, the shared system shall produce crossover claims with full SFR claim content as part of their A/B MACs (A,B, HH)’ or DME MACs’ ASC X12 837 COB flat file transmissions to the BCRC.
Effective with the testing and implementation of the HIPAA ASC X12 837 institutional claim (new and now current version), the Fiscal Intermediary Shared System (FISS) shall observe the following business rules for mapping of the ASC X12 837 COB (institutional) flat file:
1. The following segments shall not be passed to the BCRC: a. ISA (Interchange Control Header Segment); b. IEA (Interchange Control Trailer Segment); c. GS (Functional Group Header Segment); and d. GE (Functional Group Trailer Segment).
2. The shared system shall map the claim version (version 005010X223A2 upon adoption of the 5010 Errata changes) in the field of the ASC X12 837 5010 COB flat file that corresponds to the ST03 segment.
3. The BHT02 (Beginning of the Hierarchical Transaction—Transaction Set Purpose Code) shall be passed either with value 00 or 18 under the following circumstances: a. Normal claims submission to the BCRC—use “00”; and b. COBA claims repair process—use “18.”
4. The BHT03 (Beginning of the Hierarchical Transaction—Reference Identification or Originator Application Transaction ID) shall contain identifiers populated as follows: a. 23 bytes for non-COBA recovery claims as follows:
Bytes 1-9—A/B MAC (A or HH) ID (9 bytes; A/B MAC (A or HH) ID, or, 5 bytes left justified, followed by 4 spaces);
Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);
Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should increment for each ST-SE envelope);
Bytes 20-21—Claim Version Indicator (2 bytes; value =50 for 5010 claims); and
Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test; “P”—production).
Byte 23—Original versus Adjustment Claim Indicator (1 byte)
Valid values:
E—for reprocessed claims that formerly included an electronic prescribing (e-RX) negative adjustment amount;
O—for original claims;
P— for Affordable Care Act or other congressional imperative mass adjustments;
M—for non-Affordable Care Act mass adjustments tied to Medicare Physician Fee Schedule (MPFS); S—for mass adjustment claims—all others; R—for RAC adjustment claims;
A—for routine adjustment claims, not previously classified; Additionally, as of April 7, 2014:
C – for CMS-directed mass adjustment action (use specified by CMS).
V—for void/cancel only claim
Bytes 1-9—A/B MAC (A or HH) ID (9 bytes; A/B MAC (A or HH) ID, or, 5 bytes left justified, followed by 4 spaces);
Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);
Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should increment for each ST-SE envelope);
Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010 claims); and
Byte 22—COBA recovery indicator (1 byte; indicator =R).
Byte 23—Original versus Adjustment Claim Indicator (1 byte) (NOTE: For valid values see II.A.4.a directly above.)
5. The 1000-A PER (Submitter EDI Contact Information) shall be populated as follows: a. PER01—populate “1C”; b. PER02—populate “BCRC EDI Department”; c. PER03—populate “TE”; and d. PER04—populate “6464586740.”
6. The 1000-B loop NM1 (Receiver Name) denotes the crossover trading partner. If an A/B MAC (A, HHH) on FISS receives multiple COBA IDs via the BOI reply trailer (29), the shared system shall submit a separate 837 transaction for each COBA ID received. Since crossover trading partner information will be unknown to the shared systems, the shared systems shall format the following fields as indicated: a. NM101—populate “40”; b. NM102—populate “2”; c. NM103—populate spaces (the BCRC will complete); d. NM108—populate “46”; and e. NM109—include COBA ID (5-digit COBA ID obtained from the BOI reply trailer 29).
7a. To populate the 2010AA NM1 (Billing Provider Name), FISS shall complete the segments as indicated below if the incoming claim is electronic. a. NM101—populate “85”; b. NM102—populate “2”; c. NM103—derived from A/B MAC (A or HH)’s internal provider file; d. NM108—populate “XX”; and e. NM109—populate NPI value, as derived from the incoming claim.
For 2010AA N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)’s internal provider file.
7b. If the incoming claim is paper Form CMS-1450 or direct data entry (DDE), which is treated as paper, FISS shall complete the 2010AA NM1 (Billing Provider Name) segments as follows: a. NM101—populate “85”; b. NM102—populate “2”; c. NM103—derive from the A/B MAC (A or HH)’s internal provider file; d. NM108—populate “XX”; and e. NM109—derive NPI from Form Locator (FL) 56 of the Form CMS-1450 claim or applicable DDE field.
For 2010AA N3 and N4 segments, FISS shall derive the required segments from FLs 1 and 2 of the Form CMS-1450 claim or internal provider file as necessary.
8a. To populate the 2010AB NM1 (Pay-to Address Name), FISS shall complete the segments as indicated below if the incoming claim is electronic.
a. NM101—populate “87”; b. NM102—populate “2”; and c. NM103—derived from A/B MAC (A or HH)’s internal provider file.
For 2010AB N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)’s internal provider file.
8b. If the incoming claim is paper Form CMS-1450 or direct data entry (DDE), which is treated as paper, FISS shall complete the 2010AB NM1 (Pay-to Address Name) segments as follows:
a. NM101—populate “87”; b. NM102—populate “2”; and c. NM103—derived from incoming claim.
For 2010AB N3 and N4 segments, FISS shall derive the required segments from the A/B MAC (A or HH)’s internal provider file as necessary.
9. FISS shall derive the 2010AA REF (Billing Provider-TAX ID) segments as follows, regardless of incoming claim’s format:
a. For REF01—populate “EI”; and b. For REF02—derive from A/B MAC (A or HH)’s internal provider file.
10a. For the 2000A and 2310-PRV in association with incoming electronic claims, FISS shall map the PRV01, PRV02, and PRV03 segments (which have already been validated for syntactical correctness at each affiliate A/B MAC (A or HH)’s front-end) to the equivalent 837 COB flat as follows: a. For PRV01—populate “BI”; b. For PRV01—populate “PXC”; and c. For PRV03—populate taxonomy code value from incoming claim.
10b. If the incoming claim is paper Form CMS-1450 or DDE entered, FISS shall only populate the 2000A-PRV (Bill-to Taxonomy) segments within the equivalent 837 COB flat fields as follows if the reported taxonomy code is syntactically correct:
a. For PRV01—populate “BI”; b. For PRV01—populate “PXC”; and
c. For PRV03—populate taxonomy code as derived from the keying of FL 81cc(a) of the Form CMS-1450 claim form or as derived from the appropriate field from the online DDE screen.
NOTE: The only reason why the 2310A PRV cannot be included on the 837 COB flat file is that the Form CMS-1450 claim and DDE claim entry screens can only accommodate Bill-to Provider taxonomy code reporting.
11. FISS shall derive information for 2010AA PER 03, PER04, PER05, and PER06 if such information is present on the incoming electronic or paper claim or is available within the A/B MAC (A or HH)'s internal provider files. If the information is not available, or is available in incomplete form (i.e., fewer digits than required), the shared system shall not create the 2010AA PER loop within the 837 new current version COB institutional flat file.
12a. For the 2320B SBR01, in situations where there is only one (1) payer that is primary to Medicare, FISS shall apply "P" to any payer that is primary before Medicare; "S" for Medicare as the secondary payer; and "U" for all supplemental payers after Medicare.
SPECIAL NOTE: If, for example, a claim contains at least two (2) primary payers before Medicare, FISS shall reflect the first payer as 2320 SBR01="P"; the second as 2320 SBR01="S"; and, the tertiary payer, Medicare, as 2320 SBR01="T." FISS shall reflect all additional supplemental payers as SBR01="U."
12b. For 2000B SBR01 (element 1138), FISS shall apply "P" when Medicare is the primary payer and shall apply "U" for all other supplemental payers after Medicare.
13. For additional 2000B requirements, FISS shall take the following actions:
a) SBR03—map spaces; and b) SBR09—map "MC" if the COBA ID returned via the BOI reply trailer (29)=70000-79999; for all other COBA IDs, map "CI."
14. The 2010BA loop denotes beneficiary subscriber information. FISS shall populate this loop and accompanying segments within the equivalent 837 COB flat file fields as indicated below.
2010BA NM1—Subscriber Name:
a. NM101—populate "IL"; b. NM102—populate "1"; c. NM103—derive from internal beneficiary eligibility file;
d. NM104—derive from internal beneficiary eligibility file; e. NM105—derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108—populate “MI”; and g. NM109—populate the beneficiary’s Medicare beneficiary identifier.
a. N301—derive from internal beneficiary eligibility file; and b. N302—derive, as necessary, from internal beneficiary eligibility file; otherwise populate spaces.
a. N401—derive from internal beneficiary eligibility file; b. N402—derive from internal beneficiary eligibility file; c. N403—derive from internal beneficiary eligibility file; and d. N407—derive if available and applicable from internal beneficiary eligibility file; otherwise populate spaces.
NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA crossover claims when the individual data content for N401 (City) or N402 (State) or N403 (Zip/Postal Code) cannot otherwise be derived.
15. The shared systems shall populate the 2330A (Other Subscriber) NM1, N3, and N4 segments as follows:
a. NM101—populate “IL”; b. NM102—populate “I”; c. NM103—derive from internal beneficiary eligibility file; d. NM104—derive from internal beneficiary eligibility file; e. NM105—derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108—populate “MI”; and g. NM109—populate the beneficiary’s Medicare beneficiary identifier.
a. N301—derive from internal beneficiary eligibility file; and b. N302—derive, as necessary, from internal beneficiary eligibility file as necessary; otherwise populate spaces.
Upon implementation of the 5010 Errata, the shared system shall not attempt to gap-fill or systems-fill any elements (N401—N407) within this segment. Also, if these elements are available but are incomplete, the shared system shall not create the N4 segment tied to loop 2330A within the ASC X12 837 COB flat file.
a. N401—derive from internal beneficiary eligibility file; and b. N402, N403, N404, N407—derive from internal beneficiary eligibility file if available and applicable; otherwise populate spaces.
16. The 2010BB loop denotes the payer name. Per the HIPAA Implementation Guide, this loop should define the secondary payer when sending the claim to the second destination payer. Thus, since the payer related to the COBA ID will be unknown by the A/B MAC (A or HH) shared systems, FISS shall format the NM1, N3, and N4 segments as follows, with the BCRC completing any missing information:
2010BB—NM1:
a. NM101—populate “PR”; b. NM102—populate “2”; c. NM103—populate spaces; d. NM108—populate “PI”; and e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).
2010BB-N3 & 2010BB-N4:
a. N301 & N302—populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.
17. FISS shall not create the 2010AC loop within the 837 new version COB flat file.
18. If FISS notes the presence of other payers within 2320 SBR and 2330B loops that had made no financial determination on a claim prior to Medicare, as in the case of Medicare secondary payer (MSP) situations, the shared system shall not move those loops to the 837 new version COB institutional flat file. (NOTE: The shared system shall continue to populate information as received from the CWF BOI reply trailer (29) within the 2320 SBR and 2330 loops of the associated ASC X12 837 COB flat file fields.)
19. The 2330B loop denotes other payers for the claim following Medicare. All should note that there will always be one (1) 2330B that denotes Medicare as a payer, with FISS completing all required information for NM101, NM102, NM103, NM108, NM109, as well as the N3 and N4 segments.
20. For additional 2330B loop iterations relating to COB, if the A/B MAC receives multiple COBA IDs via the BOI reply trailer (29), payer information for additional COBA IDs will be unknown. As with the 2010BB loop, the NM1 segment should be formatted as follows, with BCRC completing missing information:
2nd and additional iterations of 2330B—NM1:
a. NM101—populate “PR”; b. NM102—populate “2”; c. NM103—populate spaces; d. NM108—populate “PI”; and e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).
2nd and additional iterations of 2330B-N3 & 2330B-N4:
a. N301 & N302—populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.
21. FISS shall always send at least one (1) complete iteration of 2320, 2330A, and 330B on all ASC X12 837 COB flat files.
22a. FISS shall populate the required 2310-A (Attending Provider Name), 2310B (Operating Physician Name), and 2310C (Other Operating Physician Name) NM1 segments, with information derived from the incoming electronic claim. FISS shall always populate the NM108 segment always indicating “XX” and shall derive the NPI from the incoming claim.
22b. If the incoming claim is paper or DDE entered, FISS shall derive the attending, operating, and other operating physician name from the Form CMS-1450 claim or DDE entry, or as necessary from the A/B MAC (A or HH)’s internal provider files. FISS shall always populate the NM108 segment with “XX” and shall derive the NPI from the Form CMS-1450 claim or DDE entry screen.
23. When the incoming claim is paper, Form CMS-1450 or DDE entered, FISS shall continue with all other mapping practices not otherwise addressed above when creating the outbound “skinny” 837 COB flat file. [For example, FISS shall continue to derive the discharge hour, admission date/hour, admission source code, medical record number, principal diagnosis, admitting diagnosis code, principal procedure information, occurrence codes, occurrence span codes, value codes, and condition codes from the associated FL fields of the Form CMS-1450 or from the DDE keyed information.]
24. FISS shall migrate the Line Item Control Number data from the Store and Forward Repository (SFR) to the area of the ASC X12 837 COB flat file that
corresponds to loop 2400, REF02, where REF01=6R, as per the Implementation Guide.
25. Upon implementation of the 5010 Errata changes, FISS shall take the following action with respect to the creation of the field corresponding to 2300 CL101 on the 837 COB flat file as a gap-fill or systems-fill value when necessary:
Map the value “9” (Information Not Available) to the field corresponding to 2300 CL101 on the ASC X12 837 COB flat file if the incoming claim is received in a claim format other than the new, now current version, and the CWF BOI reply trailer 29 indicator for “the new, now current version” returned to the A/B MAC (A or HH) for the claim= “T” or “P.”
Effective with the testing and implementation of the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 837 professional new and now current version, the Multi-Carrier System (MCS, the A/ B MAC (B) shared system) and the ViPS Medicare System (VMS, the DME MAC shared system) shall observe the following common business rules for mapping of the new and now current version COB (professional) flat file:
1 The following segments shall not be passed to the BCRC:
2. The shared system shall map the claim version (new and now current version) in the field of the ASC X12 837 new version COB flat file that corresponds to the ST03 segment.
3. The BHT02 (Beginning of the Hierarchical Transaction—Transaction Set Purpose Code) shall be passed either with value 00 or 18 under the following circumstances:
4. The BHT03 (Beginning of the Hierarchical Transaction—Reference Identification or Originator Application Transaction ID) shall contain identifiers populated as follows:
a. 23 bytes for non-COBA recovery claims as follows:
Bytes 1-9—A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC or DME MAC ID, or 5 bytes left justified, followed by 4 spaces);
Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);
Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should increment for each ST-SE envelope);
Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010 claims); and
Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test; “P”—production); and
Byte 23—Original versus Adjustment Claim Indicator (1 byte)-Valid Values are:
E—for reprocessed claims that formerly included an electronic prescribing (e-RX) negative adjustment amount;
O—for original claims;
P— for Affordable Care Act or other congressional imperative mass adjustments;
M—for non-Affordable Care Act mass adjustments tied to Medicare Physician Fee Schedule (MPFS);
S—for mass adjustment claims—all others;
R—for RAC adjustment claims; and
A—for routine adjustment claims, not previously classified.
Additionally, as of April 7, 2014:
C—for CMS-directed mass adjustment action (use specified by CMS);
V—for void/cancel only claim
Bytes 1-9—A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC (B) or DME MAC ID, left justified, or 5 bytes followed by 4 spaces);
Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”);
Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should increment for each ST-SE envelope);
Bytes 20-21—Claim Version Indicator (2 bytes; values=50 for 5010 claims); and
Byte 22—COBA recovery indicator (1 byte; indicator =R)
Byte 23—Original versus Adjustment Claim Indicator (1 byte)
(NOTE: See II.B.4.a directly above for valid values.)
5. The 1000-A PER (Submitter EDI Contact Information) shall be populated as follows:
a. PER01—populate “1C”; b. PER02—populate “BCRC EDI Department”; c. PER03—populate “TE”; and d. PER04—populate “6464586740.”
6. The 1000-B loop NM1 (Receiver Name) denotes the crossover trading partner. If the A/B MAC (B) or DME MAC receives multiple COBA IDs via the BOI reply
trailer (29), the shared system shall submit a separate ASC X12 837 transaction for each COBA ID received. Since crossover trading partner information will be unknown to the shared systems, the shared system shall format the following fields as indicated:
a. NM101—populate “40”; b. NM102—populate “2”; c. NM103—populate spaces; d. NM108—populate “46”; and e. NM109—include COBA ID (5-digit COBA ID obtained from the BOI reply trailer 29).
7a. For all 2000A, 2310B, and 2420A PRV (Billing Provider Specialty Information) segments, the A/B MAC ( B) and DME MAC shared systems shall map the taxonomy code values reported in PRV01 through PRV03 on the incoming electronic claim to the corresponding fields within the ASC X12 837 COB flat file. If the values reported for these loops on the incoming claim are incomplete or syntactically incorrect, the shared system shall not create the loop and associated segments.
7b. The A/B MAC (B) shared system shall continue the practice of only mapping 2420A-level PRV segments if the incoming electronic claim is multi-line, with differing rendering physicians associated to each line. The A/B MAC ( B) shared system shall not map a 2420A-level reported PRV segment if the incoming electronic claim contains a single detail line.
8. The A/B MAC (B) and DME MAC shared systems shall derive information for 2010AA PER 03, PER04, PER05, and PER06 if such information is present and syntactically complete within the A/B MAC (B) or DME MAC’s internal provider files. If such information is unavailable or incomplete, the affected shared systems shall not create the 2010AA PER loop on the ASC X12 837 new version professional COB flat file.
9. The A/B MAC (B) and DME MAC shared systems shall derive all provider specific information necessary to populate the NM1 and N3 and N4 segments of such loops as 2010AA, 2010AB, and 2310B from each A/B MAC (B) or DME MAC’s internal provider files. In addition, where a provider’s tax ID is required within a secondary REF segment, the shared systems shall also derive this information from each A/B MAC (B) or DME MAC’s internal provider files.
10a. For 2320 SBR01, in situations where there is only one (1) payer that is primary to Medicare, VMS shall apply “P” to any payer that is primary before Medicare; “S” for Medicare as the secondary payer; and “U” for all supplemental payers after Medicare.
SPECIAL NOTE: If, for example, a claim contains at least two (2) primary payers before Medicare, the DME MAC shared system shall reflect the primary payer as 2320 SBR01 as “P”; the secondary payer as 2320 SBR01 = “S”; and, the tertiary payer, Medicare, as 2320 SBR01 = “T.” MCS shall reflect all additional supplemental payers as 2320 SBR01 = “U.”
10b. For 2000B SBR01 (element 1138), the shared system shall apply “P” when Medicare is the primary payer and shall apply “U” for all other supplemental payers after Medicare.
11. For additional 2000B requirements, the shared system shall take the following actions:
a. SBR03—map spaces; and b. SBR09—If the COBA ID returned via the BOI reply trailer (29)=70000-79999, map “MC”; for all other COBA IDs, map “CI.”
12. The 2010BA loop denotes beneficiary subscriber information. There are two (2) crossover scenarios to address: regular, eligibility file-based crossover, and Medigap claim-based crossover.
(1) For regular eligibility file-based crossover (COBA ID=anything except 55000 through 59999), the shared system shall populate the NM1, N3, and N4 segments as follows:
a. NM101—populate “IL”; b. NM102—populate “1”; c. NM103—derive from internal beneficiary eligibility file; d. NM104—derive from internal beneficiary eligibility file; e. NM105—derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108—populate “MI”; and g. NM109—populate the beneficiary’s Medicare beneficiary identifier.
a. N301—derive from internal beneficiary eligibility file; and b. N302—derive, as necessary, from internal beneficiary eligibility file; otherwise populate spaces.
a. N401—derive from internal beneficiary eligibility file; b. N402—derive from internal beneficiary eligibility file;
c. N403—derive from internal beneficiary eligibility file; and d. N407—derive if available and applicable from internal beneficiary eligibility file; otherwise populate spaces.
NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA crossover claims when the individual data content for N401 (City) or N402 (State) or N403(Zip/Postal Code) cannot otherwise be derived.
(2) Medigap claim-based crossover (COBA ID=55000 through 59999 only), the shared system shall populate the NM1, N3, and N4 segments as follows:
a. NM101—populate “IL”; b. NM102—populate “I”; c. NM103—derive from internal beneficiary eligibility file; d. NM104—derive from internal beneficiary eligibility file; e. NM105—derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. M108—populate “MI”; and g. M109—populate beneficiary policy number as derived from Item 9-D of Form CMS-1500 claim or 2330B NM109 of the incoming 837 professional claim. The shared system shall only populate the beneficiary’s Medicare beneficiary identifier here if the policy number is unavailable on the incoming claim.
a. N301—derive from internal beneficiary eligibility file; b. N302—derive, as necessary, from internal beneficiary eligibility file; otherwise populate spaces.
a. N401—derive from internal beneficiary eligibility file; b. N402—derive from internal beneficiary eligibility file; c. N403—derive from internal beneficiary eligibility file; and d. N407—derive, if available, from internal beneficiary eligibility file; otherwise populate spaces.
NOTE: See “Gap-Fill” section for the values to be populated on outbound COBA crossover claims when the individual data content for N401 (City) or N402 (State) or N403 (Zip/Postal Code) cannot otherwise be derived.
13. The shared system shall populate the 2330A (Other Subscriber) NM1, N3, and N4 segments as follows:
a. NM101—populate “IL”; b. NM102—populate “1”; c. NM103—derive from internal beneficiary eligibility file; d. NM104—derive from internal beneficiary eligibility file; e. NM105—derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108—populate “MI”; and g. NM109—populate the beneficiary’s Medicare beneficiary identifier.
a. N301—derive from internal beneficiary eligibility file; and b. N302—derive, as necessary, from internal beneficiary eligibility file as necessary; otherwise populate spaces.
Upon implementation of the 5010 Errata, the A/B MAC (B) and DME MAC shared systems shall not attempt to gap-fill or systems-fill any elements (N401—N407) within this segment. Also, if these elements are available but are incomplete, the shared systems shall not create the N4 segment tied to loop 2330A within the ASC X12 837 COB flat file.
a. N401—derive from internal beneficiary eligibility file; and b. N402, N403, N404, N407—derive from internal beneficiary eligibility file if available and applicable; otherwise populate spaces.
14. The 2010BB loop denotes the payer name. Per the HIPAA Implementation Guide, this loop should define the secondary payer when sending the claim to the second destination payer. Thus, since the payer related to the COBA ID will be unknown by the shared systems, the shared system shall format the NM1, N3, and N4 segments as follows, with the BCRC completing any missing information:
a. NM101—populate “PR”; b. NM102—populate “2”; c. NM103—populate spaces; d. NM108—populate “PI”; and e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).
a. N301 & N302—populate spaces; and
b. For N401, N402, N403, N404, N407, populate spaces.
15. The shared system shall not create the 2000C or the 2010CA loops within the ASC X12 837 new version professional COB flat file.
16. If the shared system notes the presence of other payers within 2320 SBR and 2330B loops that had made no financial determination on a claim prior to Medicare, as in the case of Medicare secondary payer (MSP) situations, the shared system shall not move those loops to the ASC X12 837 new version COB professional flat file.
17. The 2330B loop denotes other payers for the claim following Medicare. There will always be one (1) 2330B that denotes Medicare as a payer, with the shared system completing all required information for NM101, NM102, NM103, NM108, NM109, as well as the N3 and N4 segments.
18. For additional 2330B loop iterations relating to COB, if the A/B MAC (B) or DME MAC receives multiple COBA IDs via the BOI reply trailer (29), payer information for additional COBA IDs will be unknown. As with the 2010BB loop, the shared system shall format the NM1 segment as follows, with the BCRC completing missing information:
a. NM101—populate “PR”; b. NM102—populate “2”; c. NM103—populate spaces; d. NM108—populate “PI”; and e. NM109—populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).
a. N301 & N302—populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.
19. The shared system shall always send at least one (1) complete iteration of 2320, 2330A, and 2330B on all ASC X12 837 COB flat files.
20. For 2300 REF (4081-Mandatory Crossover Indicator), the shared system shall take the action indicated below in accordance with the applicable scenario:
a. REF01, always map “F5”; b. REF02, map “Y” if the COBA ID returned via the BOI reply trailer (29)=55000 through 55999 (Medigap claim-based crossover); and
c. REF02, map “N” if the COBA ID returned via the BOI reply trailer (29) =anything except for 55000 through 55999 (regular crossover).
IMPORTANT: The shared system shall create an outbound new version “skinny” claim, as derived from paper/hard copy claim input, in the same manner that it now does in creating the current in-use (prior to new version) claim, unless otherwise specified above or below.
1. The shared system shall always map NDC codes keyed from hard-copy claims to the field that corresponds to 2410 LIN03 on the ASC X12 837 new version COB professional flat file. In addition, the shared system shall auto-plug the appropriate qualifier that designated NDC within the field that corresponds to 2410 LIN02.
2. If the incoming paper claim contains an NPI in block 32 of the Form CMS-1500, the shared system shall continue to utilize this keyed value for purposes of deriving the information necessary to populate all required segments associated with 2310C (Service Facility Name). The shared system shall continue to not create the 2310C loop if block 32 on the incoming paper claim is blank.
3. If the incoming claim is paper and does not contain information necessary to derive 2410 CTP5-1 (in association with Part B drugs), the shared system shall auto-plug the value “F2.”
1. For all instances of the N403 segment, where created, FISS shall ensure that it creates a 5-byte base ZIP code and additional 4-byte component for the COB flat file when required.
2. FISS shall universally gap-fill or systems-fill required individual address elements, when not otherwise obtainable, for Subscriber-related loops as follows:
N401 (City Name) = Cityville; N402 (State or Province Code) = MD; and N403 (Postal Zone/ZIP Code) = 96941.
NOTE: The above is particularly applicable in the creation of the indicated segments within the 2010BA loop when the needed data are individually not otherwise unavailable.
3. FISS shall gap-fill the +4 ZIP code component with 9998 when the actual +4 ZIP code component is unavailable when creating the N403 in association with loops 2010AA (Billing Provider) and 2310E (Service Facility). (NOTE: The full 9-byte ZIP code is required only for the N403 segment of the indicated loops.)
4. FISS shall never input "0000" as a gap-fill or system-fill +4 ZIP code in association with any of the N403 segments. 5a. If the shared system has valid city, state, and 5-byte ZIP code information available, it shall only gap-fill or system-fill the +4 ZIP code component, where required, with "9998" when creating outbound ASC X12 837 COB claim files. 5b. The shared system shall continue to send full ZIP code content (9-bytes) on outbound ASC X12 837 COB claim files, if available, for creation of situational N403 segments.
6. When the shared system determines that it has data within its internal provider file to populate 2010AA PER 04, it shall only move that information to the corresponding flat file field if the available data are complete. If the available data are incomplete (i.e., fewer than 10 digits for telephone number), the shared system shall not attempt to gap-fill the missing digits. The shared system shall also not create that PER segment.
7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME MAC's internal beneficiary eligibility record contains blank or incomplete line-1 street address information, FISS shall apply "Xs" to satisfy the minimum length requirements of the N301 segments.
8. If the incoming claim is paper Form CMS-1450 or DDE-entered and the dosage information necessary to populate 2410 CTP05-1 is not available, FISS shall always default to the value of "F2."
9. If the incoming claim is paper or electronic, FISS shall map "non-specific procedure code" within the ASC X12 837 new version COB flat file field that corresponds to loop 2400 SV202-7 (non-specific composite medical procedure description) if a non-specific procedure code description is required, as per the Implementation Guide, and the associated procedure code is defined as "not otherwise classified." (See the following link for the latest listing of not otherwise classified procedure codes: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha-Numeric-HCPCS.html?DLSort=0&DLEntries=10&DLPage=1&DLSortDir=descending&DLFilter=NOC
10. FISS shall not attempt to gap-fill or systems-fill the N4 segment (now situational) within the field corresponding to loop 2330B on the ASC X12 837 new version COB flat file. In addition, if information needed to create the N4 segment is available but is incomplete, FISS shall not create the loop 2330B N4 segment.
11. FISS shall not attempt to gap-fill or systems-fill any of the composite SVD03 elements within loop 2430.
1. For all instances of the N403 segment, where created, the A/B MAC ( B) and DME MAC shared systems shall ensure that it creates a 5-byte base ZIP code and additional 4-byte component for the COB flat file when required.
2. The A/B MAC (B) and DME MAC shared systems shall universally gap-fill or system-fill required individual address elements, when not otherwise obtainable, for all Subscriber-related loops as follows:
N401 (City Name) = Cityville; N402 (State or Province Code) = MD; and N403 (Postal Zone/ZIP Code) = 96941.
NOTE: The above is particularly applicable in the creation of the indicated segments within the 2010BA loop when the needed data are individually otherwise not unavailable.
3. The A/B MAC (B) and DME MAC shared systems shall gap-fill the +4 ZIP code component with 9998 when the actual +4 ZIP code component is unavailable when creating the N403 in association with loops 2010AA (Billing Provider), 2310C (Service Facility—claim level), and 2420C (Service Facility—service line level). (NOTE: The full 9-byte ZIP code is required only for the N403 segment of the indicated loops.)
4. The A/B MAC (B) and DME MAC shared systems shall never input “0000” as a gap-fill or system-fill +4 ZIP code in association with any of the N403 segments. 5a. If the A/B MAC (B) and DME MAC shared systems have valid city, state, and 5-byte ZIP code information available, they shall only gap-fill or system-fill the +4 ZIP code component, where required, with “9998” when creating outbound ASC X12 837 COB claim files. 5b. The A/B MAC (B) and DME MAC shared system shall continue to send full ZIP code content (9-bytes) on outbound ASC X12 837 COB claim files, if available, for creation of situational N403segments
6. When the shared system determines that it has data within its internal provider file to populate 2010AA PER 04, it shall only move that information to the corresponding flat file field if the available data are complete. If the available data are incomplete (i.e., fewer than 10 digits for telephone number), the shared system shall not attempt to gap-fill the equivalent field on the new version COB flat file.
7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME MAC's internal beneficiary eligibility record contains blank or incomplete line-1 street address information, the shared system shall apply "Xs" to satisfy the minimum length requirements of the N301 segments.
8a. In association with paper-submitted Part B ambulance claims, the A/B MAC (B) shared system shall apply gap-filling to the N3 and N4 portions of loop 2310E and 2310F as follows for the segments indicated:
For N301: The A/B MAC (B) shared system shall map "Xs" to the minimum standard required for the field.
For N401—N403: The A/B MAC (B) shared system shall undertake the following actions:
N401 (City)—populate "Cityville"; N402 (State Code)—populate "MD"; and N403 (Postal Zone/ZIP Code)—populate "96941."
8b. In addition, the A/B MAC (B) shared system shall gap-fill the required +4 component of ZIP code (N403 segment) with 9998 only in association with loops 2010AA, 2310C, and 2420C.
9. The shared system shall map "UN" in the ASC X12 837 new version COB flat file field that corresponds to loop 2410 (CTP) and segment CPT04 only when the 2410 (CTP) CTP04 segment is either blank or contains a non-valid value.
10. The shared system shall apply the gap-fill value "X" to the field corresponding to loop 2430 (SVD) and segment SVD03-2 in situations where the value on the incoming claim is either missing or non-valid.
11. The A/B MAC (B) shared system shall discontinue the process of gap-filling diagnosis code information within loop 2300 HI in association with ambulance claims that ambulance suppliers file to Medicare on paper.
12a. Following adjudication of both electronic and paper billed claims, the shared system shall discontinue the practice of applying gap-fill values of all "9s" within the ASC X12 837 new version COB flat file field that corresponds to 2410 LIN03 if the incoming claim contains an incomplete or non-valid national drug code (NDC). If an incoming paper claim contains a syntactically non-valid NDC code that the A/B MAC (B) or DME MAC subsequently keys, the shared system shall not attempt to gap-fill the field that corresponds to 2410 LIN03 on the ASC X12 837 new version COB flat file.
12b. The DME MAC shared system shall gap-fill the loop 2430 (SVD) SVD03-2 segment with "S5000" or "S5001," as appropriate, in situations where the incoming claim contains an NDC within the 2410 LIN02 that does not correspond to a HCPCS on the NDC/HCPCS crosswalk.
13. If the incoming claim is paper and A/B MAC or DME MAC's internal provider file contains incomplete information necessary to populate the 2310C loop (in cases where required), the shared system shall gap-fill all required segments with "Xs." NOTE: The shared system shall discontinue the practice of mapping "submitted but not forwarded" as a gap-fill convention in this situation for segments where information is required.
14. If the incoming claim is paper or electronic, the shared system shall map "non-specific procedure code" within the ASC X12 837 COB flat file field that corresponds to loop 2400 SV202-7 (non-specific composite medical procedure description) if a non-specific procedure code description is required, as per the Implementation Guide, and the associated procedure code is defined as "not otherwise classified." (See the following link for the latest listing of not otherwise classified procedure codes: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha-Numeric-HCPCS.html?DLSort=0&DLEntries=10&DLPage=1&DLSortDir=descending&DLFilter=NOC
15. The A/B MAC (B) shared system shall utilize the claim's earliest service date to satisfy the requirement for 2300 DTP03 (date of admission), where required, in association with claims whose place of service code is 21, 51, or 61.
16. The A/B MAC (B) shared system shall populate 99 as a gap-fill/default value for loop 2300 (CLM) segment CLM05-1 (Facility Type Code) within the corresponding field of the ASC X12 837 new version COB flat file.
17. For ambulance claims, the A/B MAC (B) shared system shall map LB in the ASC X12 837 new version COB flat file field the corresponds to 2400 CR101 if that field would otherwise contain spaces where there is a value (weight) present in 2400 CR102.
18. Also, for ambulance claims, the A/B MAC (B) shared system shall produce spaces in the field that corresponds to loop 2400 CR101 when loop 2400 CR102 on the incoming claim is blank.
19. All shared systems shall not attempt to gap-fill or systems-fill the N4 segment (now situational) within the field corresponding to loop 2330B on the ASC X12 837 COB flat file. In addition, if information needed to create the N4 segment is available but is incomplete, the shared systems shall not create the loop 2330B N4 segment.
Upon receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) that contains a “P” ASC X12 837 indicator, the shared systems shall ensure that their affiliate A/B MACs and DME MACs are able to: 1) book complementary credits for the affected claim; and 2) transmit the “production” claim to the BCRC after it has finalized on the A/B MAC or DME MAC’s payment floor.
Following receipt of a BOI reply trailer (29) that contains a “T” ASC X12 837 indicator, as applicable, the shared systems shall ensure that their affiliate MACs: 1) do not anticipate receipt of complementary credits for that version of the claim; and 2) transmit the “test” claim to the BCRC after it has finalized on the contractor’s payment floor.
All shared systems shall, in addition, not expect complementary credits in association with their affiliated A/B MAC or DME MAC’s receipt of a CWF BOI reply trailer (29) that contains an “N” new version indicator.
With the implementation of the new version claim standards, the BCRC will apply business level edits to ensure that incoming claims possess the structure necessary for successful translation into the HIPAA ASC X12 837 new version claim formats. See §70.6.1.1 of this chapter for charts that define the “111” level errors that the BCRC will return to the A/B MACs or DME MACs when their incoming ASC X12 837 COB flat files cannot be utilized to build compliant outbound ASC X12 837 claim transactions.
The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary’s Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.
Prior to the mandatory cut-over to the NCPDP new batch telecommunications claim version, the DME MAC shared system shall develop a current, in-use format “skinny” non-SFR claim format to accommodate those situations where COBA trading partners are unable to accept pharmacy-submitted claims in the NCPDP new version format. In addition, the DME MAC shared system shall develop an NCPDP new version “skinny” non-SFR format that addresses the scenario of claims originally adjudicated in the
NCPDP current, in-use format and later adjusted after the NCPDP new version format is required in association with all incoming and outgoing NCPDP new version claims.
The DME MAC shared system shall also develop an NCPDP new version “skinny” non-SFR format that addresses the scenario of claims that a DME MAC originally adjudicated in the NCPDP current, in-use format but suspended for a period of time that meets or transcends the date by which the NCPDP new version format is required in association with all incoming and outgoing NCPDP new version claims.
With respect to the NCPDP new version COB flat file submissions to the Benefits Coordination & Recovery Center (BCRC), the ViPS Medicare System (VMS) maintainer shall observe the following business rules for mapping:
1. The 504-F4 (“Message”) Trailer portion of the file shall contain a 22-byte identifier populated as follows:
a.) Bytes 1-9—Contractor ID (9 bytes; DME MAC ID, or, 5 bytes left justified, followed by spaces); b.) Bytes 10-14—Julian Date (5 bytes, expressed as “YYDDD”); c.) Bytes 15-19—Sequence Number (5 bytes, starting with “00001”; should increment for each ST-SE envelope); d.) Bytes 20-21—Claim Version Indicator (2 bytes; values= 20 for NCPDP version D.0 claims); and e.) Byte 22—Test/Production Indicator (1 byte; valid values=”T”—test; “P”—production).
1. Create 101-A1 (“BIN assigned number”) with spaces.
2. Create the claim version release number (102-A2) within the Transmission/Transaction Header Segment.
3. Populate the appropriate transaction code (103-A3), the processor control number (104-A1), and transaction count value (109-A9).
4. Always map the service provider ID qualifier corresponding to the national provider identifier (NPI) in 202-B2.
5. Always map the supplier's NPI in 201-B1 ("Service Provider ID").
6. Map date of service from incoming claim for 401-D1.
7. Map 110-AK ("Software Vendor/Certification ID") from incoming claim.
IMPORTANT: For "skinny" NCPDP current, in use claim scenarios, where the incoming claim is the current, in use version NCPDP, the shared system shall map "unknown" in 110-AK.
1. Map the beneficiary's Medicare beneficiary identifier in 302-C2 ("Cardholder ID").
2. Map 312-CC and 313-CD ("Cardholder's First and Last Names") using information from the DME MAC's internal eligibility file.
3. Do not create 301-C1 ("Group ID"), as CMS no longer authorizes claims-based transfers to Medicaid State Agencies.
4. Do not create 336-8C ("Facility ID"), even in "skinny" claim situations.
5. For Medigap claim-based crossover purposes only, the shared system shall continue to populate the Medigap claim-based COBA ID (range 55000-55999) in the flat file field corresponding to 301-C1 (Group ID), as derived from the incoming claim.
In addition, the shared system shall populate the Medigap policy ID in the newly created 359-2A (Medigap ID) element, as derived from the incoming claim.
6. Always map an "A" value for element 361-2D ("Provider Accept Assignment Indicator").
7. Do not create elements 115-N5, 116-N6, 314-CE, 303-C3, and 306-C6.
8. Create 524-F0 ("Plan ID") in the future only when CMS directs.
1. Create element 331-CX ("Patient ID Qualifier") as appropriate.
2. Create 307-C7 ("Place of Service") based upon the incoming claim.
3. Always map the beneficiary's Medicare beneficiary identifier in 332-CY ("Patient ID").
4. Map elements 304-C4, 305-C5, 310-CA, and 311-CB from the DME MAC's internal beneficiary eligibility file.
5. Map elements 322-CM, 323-CN, 324-CO, and 325-CP from the DME MAC's internal beneficiary eligibility file. (*--See Gap Filling Requirements in Attachment B to address situations where the beneficiary's line-1 address, as derived from the DME MAC's internal beneficiary eligibility file, is blank or incomplete.)
6. Map 326-CQ ("Patient Phone Number") and 350-HN ("Patient E-mail Address") from incoming claim. (Assumption: CEDI will ensure these values are syntactically correct as a condition of inbound claim acceptance.)
7. Do not create element 335-2C ("Pregnancy Indicator") on the NCPDP new version COB file.
1. Map element 466-EZ ("Prescriber ID Qualifier") from the incoming claim.
2. Always map "01" for element 468-2E ("Primary Care Provider ID Qualifier").
3. Map the NPI, as derived from the incoming claim, in element 421-DL ("Primary Care Provider ID").
4. Map the supplier's name, as derived from the DME MAC's internal provider files, for 470-4E ("Primary Care Provider Last Name").
5. Map 411-DB based upon adjudicated claim data.
6. Map 427-DR ("Prescriber Last Name") and 364-2J ("Prescriber First Name") from the DME MAC's internal supplier files.
7. Map 365-2K ("Prescriber Address"), 366-2M ("Prescriber City"), 367-2N ("Prescriber State"), 368-2P ("Prescriber Zip"), and 498-PM ("Prescriber Phone Number") based upon the availability of these elements in the SFR. (See Attachment B for special gap-filling requirements that will come into play for NCPDP skinny mapping.)
1. Map element 337-4C from the incoming claim.
2. Prepare element 338-5C to appropriately qualify deductible or co-insurance remaining. (NOTE: In the case of adjustment claims, where the DME MAC used 98 or 99 previously, the shared system shall populate the NCPDP new version equivalent qualifying value on the COB flat file.)
3. Map value "05" for element 339-6C in relation to Medicare's role as payer of the claim.
4. Map the DME MAC's workload identifier (e.g., 16003) in element 340-7C.
5. Map the Internal Control Number (element 993-A7) as received from CEDI and as a result of claim adjudication.
6. Map the following out on the COB flat file only if received on the incoming claim: 443-E8, 341-HB, 342-HC, 431-DV, 471-5E, 472-6E.
7. Create 353-NR, 351-NP, and 352-NQ in terms of primary payer's patient responsibility count, qualifier, and remaining amount, as applicable, or the patient responsibility count, qualifier, and remaining amount after Medicare.
8. Do not map 392-MU, 393-MV, and 394-MW, as these are not used for Medicare purposes.
9. Do not create any portion of the Transaction Workers' Compensation Segment.
1. Map 343-HD, 344-HF, and 345-HG based upon availability on the data on the incoming claim.
2. Create 455-EM and 402-D2 as required, without gap-filling.
3. Create 403-D3, 405-D5, 406-D6, and 407-D7 as required, without gap-filling.
4. Create all of the following if received on the incoming claim: 408-D8, 414-DE, 415-DF, 418-DI, 419-DJ, 420-DK, 453-EJ, 445-EA, 446-EB, and 457-EP. (NOTE: Gap-filling of 453-EJ with spaces is acceptable if the shared system is also concurrently gap-filling 445-EA with spaces.)
5. Create procedure modifier count (458-SE) based upon claim adjudication.
6. Create procedure modifier code as appropriate.
7. Map 442-E7 and 426-E1 as required, without gap-filling.
8. Create 456-EN, 420-DK, 308-C8, and 429-DT to the COB file if received on the incoming claim.
9. Map 454-EK (now required in certain situations) and 600-2B if received on the incoming claim.
10. Do not create 461-EU, 462-EV, 463-EW, 464-EX, 354-NX, 357-NV, 995-E2, 996-G1, and 147-U7 if received on the incoming claim.
11. Always create 391-MT ("Patient Assignment Indicator") on the COB flat file. (NOTE: CEDI shall reject NCPDP claims with this element missing at the DME MAC's front-end.)
1. Create all of the following required elements without gap-filling: 447-EC, 448-ED, 449-EE, 450-EF, 451-EG, 488-RE, and 489-TE.
2. Create the following based upon claims adjudication: 412-DC, 423-DN, 426-DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480-H9.
3. Create the following if received on the incoming claim: 490-UE, 362-2G, and 363-2H.
1. Create the following required elements without gap-filling: 409-D9 and 430-DU.
2. Create the following based upon claims adjudication: 412-DC, 423-DN, 426-DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480-H9.
3. Do not create 482-GE, 483-HE, and 484-JE.
1. Create all situational elements indicated only if received.
2. Do not create "Transaction Additional Doc" segment or Additional Documentation Type ID (369-2Q), as they relate to passage of CMN information, which is no longer supported.
Create associated elements only if received; otherwise, do not attempt to gap-fill.
Create the 390-BM (Narrative Message) element only if information is populated on the inbound NCPDP new version batch claim.
The DME MAC shared system shall observe the following gap-filling requirements when creating NCPDP new version COB flat files for transmission to the BCRC:
A. For rare instances where there is not a valid base 5-byte zip code available to populate a required zip code field, VMS shall populate "96941" within the field corresponding to that segment on the NCPDP new version COB flat file.
B. With respect to element 322-CM (Transmission Patient Segment), when the DME MAC's internal beneficiary eligibility record contains blank or incomplete line-1 street address information, VMS shall populate this element with an initial "X" followed by 29 spaces.
C. The shared system shall continue the practice of gap-filling element 453-EJ (Originally Prescribed Product/Service ID Qualifier) when element 445-EA (Originally Prescribed Product Service Code) is gap-filled with spaces.
D. The shared system shall continue the practice of gap-filling 446-EB (Originally Prescribed Quantity) when the value for this element from the inbound claim is present but non-numeric.
E. For "skinny" processing, the shared system shall initialize elements 498-PM, 364-2J, 365-2K, 366-2M, 367-2N to spaces as a gap-fill measure.
F. For "skinny" processing, the shared system shall initialize element 368-2P to zeroes as a gap-fill measure.
G. If element 427-DR ("Prescriber Last Name") cannot be found within the DME MAC's internal supplier files, the shared system shall set element 427-DR to "Unknown."
SPECIAL NOTE: When DME MACs encounter particular gap-filling scenarios that are not specifically addressed above, their shared system shall deploy the current gap-fill requirements for the creation of required NCPDP current, in use version COB flat file data content when creating NCPDP new version COB flat files for transmission to the BCRC.
In advance of their acceptance of incoming NCPDP new version claims, all DME MACs shall inform their affiliate “participating” suppliers that they may initiate Medigap claim-based crossover processes by taking the following steps:
The BCRC shall effectuate cut-over of COBA trading partners to the NCPDP new claim format through actions taken via the COIF.
Upon receipt of a CWF BOI reply trailer (29) that contains a “P” NCPDP new version indicator and an “N” current, in-use (or old version) NCPDP format indicator, VMS shall cease creation of NCPDP current, in-use (or old version) full COB claim or NCPDP current, in use (or old version) non-SFR skinny COB claims as well as transmission of these files to the BCRC.
During the NCPDP new version transitional period, all DME MACs shall accept and process two BCRC Detailed Error Reports—one generated by the BCRC for claims transmitted by the DME MACs in the current, in-use (or old) version NCPDP COB flat file format, and another generated by the BCRC for claims transmitted by the DME MACs in the new version NCPDP COB flat file format.
The DME MAC shared system now accept “222” error conditions as part of the BCRC Detailed Error Report for NCPDP claims, as may be referenced in §70.6.1 of this chapter. In this vein, the DME MAC shared system shall not effectuate changes to expand the error description field portion of the BCRC NCPDP Detailed Error Report to accommodate receipt of the new “222” errors.
Effective with July 2012, the BCRC will return the following new “222” errors to DME MACs via the BCRC NCPDP Detailed Error Reports:
N22230—NCPDP current, in use or old version “production” claim received, but the COBA trading partner is not accepting that version NCPDP “production” claims;
N22231—Current, in use or old version NCPDP “test” claim received, but the COBA trading partner is not accepting that version NCPDP “test” claims;
IMPORTANT: The BCRC shall not begin applying “222” editing to incoming claims until 14 calendar days after a COBA trading partner’s production cut-over to the NCPDP new version format have elapsed. The DME MACs shall not attempt to repair claims that the BCRC returns via the BCRC Error Reports with error codes N22230 through N22233, regardless of error percentage.
All DME MACs shall create special provider letters to their affiliate supplier, in accordance with §70.6.1 of this chapter, for “production” claims with error codes N22230 or N22232.
The DME MACs, working with their shared system, shall initiate new version NCPDP COB claims repair actions when: 1) the error percentage for “333” errors equals or exceeds four (4) percent; and 2) they receive even one (1) “111” error as noted on the BCRC Detailed Error Reports.
As part of their process to initiate a claims repair, the DME MACs shall alert their shared system or Data Center, as per established protocol. The DME MACs shall also suppress generation of their provider notification letters, in accordance with §70.6.1 of this chapter, for up to 14 days.
If the DME MACs determine that the timeframes for effectuating claim repairs for “111” or “333” errors fall outside of acceptable CMS parameters (e.g., will take 30-60 days or longer) or if the volume of affected claims is low (1,000 claims or less per week), the DME MACs shall allow for the release of their special provider notification letters to affected suppliers. Any DME MACs that wish to effectuate a repair of NCPDP “production” claims whose error percentage falls below four (4) percent shall contact a member of the CMS COBA team before attempting that action. As a rule, CMS will grant approval for such a repair if the volume of errored claims justifies that action and if the time frame for repair is acceptable.
While DME MACs will not be expected to initiate the repair of “test” NCPDP claims, they shall continue to: 1) monitor the BCRC Detailed Error Reports; and 2) notify their shared systems of errors returned so that necessary shared system changes to improve HIPAA compliance rates may be realized.
IMPORTANT: The DME MAC shared system shall apply NCPDP non-SFR “skinny” logic to claim repair situations where they originally transmitted claims to the BCRC prior to January 1, 2012, in the NCPDP prior version claim format.
(Rev. 4069, Issued: 06-08-18, Effective: 07-09-18, Implementation: 07-09-18)
The outbound COB transaction is a post-adjudicative transaction. This transaction includes the incoming claim data as well as the COB data. A/B MACs or DME MACs are required to receive all possible data on the incoming 837, although they do not have to process non-Medicare data. However, the shared system must store that data in a store-and-forward repository (SFR). This repository file is designed and maintained by the shared system. This data must be re-associated with the Medicare claim and payment data in order to create a compliant outbound COB transaction using the Medicare Claim/COB flat file as input. The shared system is to use post-adjudicative Medicare data (data used from history and reference files to adjudicate the claim) instead of data received when building the outbound COB transaction. This is to show any changes in data element values as a result of claims adjudication. The shared system must retain the data in the SFR for a minimum of six months.
The Medicare Claim/COB flat file is the format to be used to re-associate all data required to map to the COB transaction.
Data on claims that the A/B MAC or DME MAC receives from its keyshop or image processing systems may not be included on the SFR, depending on the shared system design. The A/B MAC and DME MAC will create the Medicare claim/COB flat file using data available from claims history and reference files. Since some data will not be available on these “paper” claims, the outbound COB transaction will be built as a “minimum” dataset. It will contain all “required” COB transactions segments and post-adjudicative Medicare data.
The steps from receipt of the incoming claim to creation of the outbound COB are summarized below:
NOTE: There are no changes in core system data fields or field sizes.
Non-Medicare data (and Medicare data elements where field sizes are in excess of the core system) are written to the SFR; and adjudicated data are combined with repository
data to create the outbound COB. Under the COBA process, the BCRC will receive flat files containing processed Medicare claims. The BCRC will then convert the flat files into the appropriate HIPAA outbound COB format and transmit the claims to the COBA trading partner.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The outbound COB transaction is a post-adjudicative transaction. This transaction includes the incoming claim data as well as COB data. A/B MACs (A) are required to receive all possible data on the incoming ASC X12 837 although they do not have to process non-Medicare data. However, the shared system must store that data in a SFR. This repository file will be designed and maintained by the shared system. This data must be re-associated with Medicare claim and payment data in order to create an IG compliant outbound COB transaction using the Medicare Part A Claim/COB flat file as input. The shared system is to use post-adjudicated Medicare data (data used from history and reference files to adjudicate the claim) instead of data received when building the outbound COB transaction. The shared system must retain the data in the SFR for a minimum of six months.
The Medicare Part A Claim/COB flat file is the format to be used to re-associate all data required to map to the COB transaction. The translator will build the outbound COB transaction from the Medicare Part A Claim/COB flat file.
The shared system maintainer must accommodate the COB transaction.
A/B MACs (A) shall refer to §70.6 through 70.6.5 for additional guidance concerning the national COBA crossover process.
The following summarizes all A/B MAC (A) steps from receipt of the incoming claim to creation of the outbound COB:
A/B MAC (A)'s translator/edit process performs syntax edits, IG edits, and Medicare edits and maps incoming claim data to the Medicare Part A Claim/COB flat file;
Medicare data on the Medicare Part A Claim/COB flat file is mapped to the core system by the shared system.
NOTE: No changes are being made to core system data fields or field sizes;
Non-Medicare data (and Medicare data elements where field sizes are in excess of the core system) are written to the SFR by the A/B MAC (A)'s shared system; and
Adjudicated data is combined with SFR data to create the outbound COB transaction.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The outbound COB transaction is a post-adjudicative transaction. This transaction includes incoming claim data as well as COB data. A/B MACs (B)/DME MACs are required to receive all possible data on the incoming ASC X12 837 although they do not have to process non-Medicare data. However, they must store that data in a store-and-forward repository (SFR). This repository will be designed by the shared system. This data must be re-associated with Medicare claim and payment data in order to create an outbound ASC X12 837 COB transaction. The shared systems maintainer is to use post-adjudicated Medicare data (data used from history and reference files to adjudicate the claim) instead of data received when building the outbound COB transaction. A/B MACs (B)/DME MACs must retain the data in the SFR for a minimum of six months.
The ASC X12-based flat file is the format to be used to re-associate all data required to map to the outbound ASC X12 837. The translator will build the outbound ASC X12 837 COB from the ASC X12-based flat file.
The shared system maintainer must create the outbound ASC X12 837.
The following summarizes all the steps from receipt of the incoming claim to creation of the outbound COB:
A/B MAC (B)/DME MAC's translator performs syntax edits and maps incoming claim data to the ASC X12 flat file;
Standard system creates implementation guide and Medicare edits for the flat file data;
NOTE: No changes are being made to core system data fields or field sizes.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
All MACs should give high priority to fraud complaints made by Medicare supplemental insurers. If the referral by a Medigap insurer includes investigatory findings indicating fraud stemming from site reviews, beneficiary interviews, provider interviews and /or medical record reviews, all MACs should (a) conduct an immediate data run to determine possible Medicare losses and (b) refer the case to the Office of the Inspector General (OIG).
In addition to the referral of such cases to the OIG, all MACs should also identify and take additional corrective action to prevent future improper payments (e.g., by placing the provider or supplier's claims on prepayment review). All MACs are responsible for taking reasonable and appropriate measures to protect the Trust Fund.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Although most States have some type of penalty provisions regarding fraud and misrepresentation in the sale of health insurance policies, Congress considered that many State laws either did not directly address the following types of abuses, or else the sanctions generally available under State laws were considered too limited. Therefore, in order to provide an additional avenue for prosecution of these cases as well as to provide stiff penalties (fines up to $25,000 and/or imprisonment for up to five years) these provisions were included in Section 507 of P.L. 96-265.
A. Section 1882(d)(l) - This paragraph prohibits the making of a false representation with regard to the compliance of a policy with the Federal requirements contained in this law. Additionally, it prohibits the making of any false statement or misrepresentation
with respect to the use of the emblem that signifies the Secretary's certification of a policy under the Voluntary Certification Program. Policies submitted under this Voluntary Certification Program were accepted for review by the Medigap Operations Staff beginning January 1, 1982. Any agent or company which represents that its policy has received the Secretary's certification, or that its policy has received or is eligible for the Secretary's emblem, when, in fact, it has not received such certification or emblem, can be prosecuted under this paragraph. This paragraph became effective June 9, 1980.
B. Section 1882(d)(2) - This paragraph prohibits the false representation of an association or agency relationship with the Medicare program or any Federal agency for the purpose of selling insurance. Of the complaints received by CMS, the majority involves alleged violations of this paragraph. These complaints indicate that agents gained entry and, in some cases, sold policies by misrepresenting, either by direct statement or by implication, that they were associated with Medicare, CMS, or the Social Security Administration. This paragraph became effective June 9, 1980.
C. Section 1882(d)(3) - This paragraph provides penalties for knowingly selling duplicative coverage (sometimes referred to as 'stacking' or 'loading).' This occurs when an agent sells insurance to an individual knowing that it duplicates coverage that he/she already has without duplicating benefits. This paragraph became effective June 9, 1980.
Although many States have statutes that specifically prohibit 'twisting' (misrepresentations made by an agent for the purpose of inducing the policyholder to lapse, forfeit, or convert a policy), few States have specific prohibitions against 'stacking.' Therefore, Federal prosecution under §1882(d)(3) may prove to be a useful approach where the available State statute does not specifically prohibit 'stacking.' Moreover, the Federal sanctions available for misrepresentations and 'stacking' may prove to be useful for prosecution where the available State sanctions are more limited.
D. Section 1882(d)(4) - This paragraph provides penalties for knowingly soliciting, advertising, or offering for sale Medicare supplemental health insurance policies by mail into a State if these policies have not been approved by the Commissioner of Insurance for sale within the State or are not deemed to be approved for sale within the State. Section 1882(d)(4)(B) sets out the situations for deeming that a policy is approved within a State.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
Representatives of CMS, the Office of the Inspector General (OIG) and the Department of Justice (DOJ) have consulted to develop a coordinated procedure for the screening, investigation, and prosecution of cases arising under these penalty provisions.
The Fraud Section, DOJ, has expressed great interest in the prosecution of these cases and has sent an official communiqué to all U.S. Attorneys addressing the existence and
importance of the Medigap law and alerting them to the probability of referrals of cases developed jointly by CMS, OIG, and by State Insurance Departments.
The CMS and OIG have reached the following agreement as to the division of functional responsibilities with regard to the screening and investigation of alleged violations of §1882(d):
1. CMS, through its regional offices, is responsible for the preliminary screening of complaints and for providing information regarding the complaints to the appropriate State Insurance Department.
2. The OIG is responsible for the investigation of cases referred by the CMS RO and for coordinating investigatory activities with the State Insurance Departments if requested and warranted. Further, OIG will provide any necessary liaison between State Insurance Departments and the U.S. Attorneys.
Upon receipt of a complaint, the RO sends an informational copy of the complaint and any supporting documentation to the Regional Office of the Inspector General. The Special Agents in Charge will serve as the OIG contact point for CMS referrals.
Additionally, the RO sends a copy of the original complaint and any supporting documentation to the appropriate State Insurance Department. This is to be accompanied by a request for information as to the status of any State investigation regarding the same agent or company or the specific case in question.
1. If the State indicates that it is currently investigating, or intends to investigate the agent or company, the RO provides any information which may be helpful to the State and advise the State of the existence of the Federal penalty provisions and the availability of investigatory advice and/or assistance from the Regional Office of the Inspector General.
If the facts also indicate that a Federal violation may exist, the RO should keep the file open and request that the State advise them as to the status and, eventually, the disposition of the case.
If the facts indicate a possible State violation but no Federal violation, the RO out the case after referring it to the appropriate State Insurance Department.
In either event, the RO should respond to the complainant that the case has been referred to the State Insurance Department for investigation. The RO sends a copy
of this response to the State, Regional OIG, and to the Medigap Operations Staff (MOS).
2. Where the State indicates that it does not plan to take action on the case, or where no response is received from the State within a reasonable period of time, i.e., not more than 30 days, the RO should proceed to screen the case. This activity consists of:
Verifying the facts alleged in the complaint; and
Determining whether the facts appear to constitute prohibited activity.
3. Where preliminary screening indicates that a mistake of fact exists, or that the facts do not indicate a Federal violation, the RO should respond to the complainant and attempt to clarify the misunderstanding. The RO sends a copy of the RO response to the complainant to MOS, the Special Agent in Charge, and the appropriate State Insurance Department.
Verification of Facts - The A/B MAC (A, B, HH) or DME MAC logs in complaints as they are received and establishes appropriate procedures to ensure that follow-up action is taken on any request for additional information. Verification of facts may include interviewing the complainant (either by phone or in person, as appropriate) to:
In interviewing the complainant and others, keep in mind the substantive facts that may lead to prosecution. The MAC uses the suggested format for referral to the Regional OIG as a checklist for the interview. As far as possible, the RO should keep the complainant informed of the status of the action taken on the complaint. So as to maintain a high level of cooperation; inform the complainant when he can expect to be contacted again, who will contact him, etc.
It is important that the RO not directly contact either the agent or the insurance company involved since this falls within the purview of investigation and is the function of the OIG.
Referral to the Regional Office of the Inspector General - When the preliminary screening process reveals an indication that the Federal law has been violated, refer the case to the Regional OIG for additional development. The OIG performs the necessary
investigation and coordinates with the appropriate U.S. Attorney for prosecution. At this point, CMS will cooperate with any request by the U.S. Attorney, State Insurance Department, and OIG to promote timely and successful prosecution.
If there should be any questions regarding this screening and referral activity, contact the Director, Medigap Operations Staff at the address below.
Centers for Medicare & Medicaid Services Director, Medigap Operations Staff 7500 Security Blvd. Baltimore, Maryland 21244-1850
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The Regional Office should perform preliminary screening activities, which may include interviewing the complainant in person or by phone (if appropriate), in order to reach a determination as to referral of the case for further investigation to the Special Agent in Charge, Office of Investigations, Regional Office of the Inspector General, HHS.
At the point where the RO believes that there exists an indication of the violation of one of the Federal penalty provisions, the RO should prepare a formal referral to the Regional OIG. In cases where there is uncertainty as to whether the Federal law has been violated, the case should be referred notwithstanding the uncertainty. The referral should reflect the following information:
A. Type of violation, e.g., the complainant alleges a violation of §1882(d)(2);
B. Name, address, and telephone number of the complainant; and
C. A narrative description of the facts, which should include:
1. All circumstances regarding the contact made by the subject with the beneficiary:
a. Type of contact (phone, personal);
b. Stated reason (if any) for selection of the beneficiary by the subject making the contact, e.g.:
i. Beneficiary lives in a senior citizens community or complex; ii. The existence of another insurance policy with the same company; and
iii. Referral by a third party.
2. Date, time, place, and duration of all contacts;
3. Words that were used to gain entry into the beneficiary's home, e.g., "I'm from Medicare," "SSA," or other Federal Government agency;
4. Details of the subject's sales pitch or presentation: a. Was there a discussion of the existence of other health insurance policies currently held by the beneficiary? b. Did the agent know that his policy was duplicative of Medicare or a currently held policy? c. Amount of premium of policy that agent was trying to sell. Obtain a copy of the policy if possible; d. Existence of any hard sell or intimidation tactics on the part of the agent.
5. Details of the Agent's exit: a. Business card left by agent; and b. Follow-up calls by agent or others.
D. Other Information:
1. Name of contact person in the Regional Office;
2. Copy of the original complaint; and
3. Any other supporting documentation.
The RO's should submit to the Director, Medigap Operations Staff, a report summarizing activities with regard to the screening and referral of complaints falling under the penalty provisions of §1882(d). This report will be used to compile the Secretary's report to Congress as required by §1882(f)(2). Under the terms of this paragraph, the Secretary must submit a report to Congress beginning July 1, 1982 (and at least every two years
thereafter) evaluating, among other things, the effectiveness of the criminal penalties. The following information from the Regional Offices is necessary for that evaluation.
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The number of complaints received broken down by the type of alleged violation, e.g., §1882(d)(2).
The origin of the complaints:
(Rev. 2906, Issued: 03-14-14, Effective: 04-14-14, Implementation 04-14-14)
The RO provides information as to the overall success of the complaint validation and referral procedure including the extent of cooperation among CMS, OIG, State Insurance Departments, and the U.S. Attorneys. This information will be used to correct or strengthen existing procedures.
This report should be submitted by the 15th of the month following the report quarter.
| 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 |
| R11939CP | 04/05/2023 | Process Improvements for the National Coordination of Benefits Agreement (COBA) Detailed Error Reporting Notification Process | 07/06/2023 | 13154 |
| R10638CP | 03/09/2021 | Modernization of the Electronic Files Transfer (EFT) Associated with the National Coordination of Benefits Agreement (COBA) Crossover Process | 04/05/2021 | 12053 |
| R10559CP | 01/20/2021 | Modernization of the Electronic Files Transfer (EFT) Associated with the National Coordination of Benefits Agreement (COBA) Crossover Process- Rescinded and replaced by Transmittal 10638 | 04/05/2021 | 12053 |
| R4281CP | 04/19/2019 | Update to Chapter 28 in Publication (Pub.) 100-04 to Provide Language-Only Changes for the New Medicare Card Project | 05/20/2019 | 11261 |
| R4243CP | 02/15/2019 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process | 04/01/2019 | 10961 |
| R4160CP | 11/02/2018 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process- Rescinded and replaced by Transmittal 4243 | 04/01/2019 | 10961 |
| R4157CP | 11/02/2018 | Hospital and Critical Access Hospital (CAH) Swing-Bed Manual Revisions and Shared Systems Changes | 04/01/2019 | 10961 |
| R4069CP | 06/08/2018 | Alignment of Coordination of Benefits Agreement (COBA) Internet Only Manual References | 07/09/2018 | 10737 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R3714CP | 02/03/2017 | Changes to the National Coordination of Benefits Agreement (COBA) Crossover Process as a Result of the Social Security Number Removal Initiative (SSNRI) | 07/03/2017 | 9885 |
| R3004CP | 08/01/2014 | Modification to the National Coordination of Benefits Agreement (COBA) Crossover Process | 01/05/2015 | 8731 |
| R2906CP | 03/14/2014 | Pub 100-04, Chapter 28 language-only update for ASC X12 version 5010, implementation of MACs, and MAC coordination with Medigap, Medicaid and Other Complementary Insurers | 04/14/2014 | 8540 |
| R2904CP | 03/14/2014 | Pub 100-04, Chapter 28 language-only update for ASC X12 version 5010, implementation of MACs, and MAC coordination with Medigap, Medicaid and Other Complementary Insurers | 04/14/2014 | 8540 |
| R2810CP | 11/07/2013 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process | 04/07/2014 | 8454 |
| R2569CP | 10/26/2012 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process | 04/01/2013 | 8071 |
| R2215CP | 05/13/2011 | Modifications to the COBA Process for Other Federal Payer Payment Order and Other Issues | 10/03/2011 | 7393 |
| R2189CP | 04/04/2011 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process Stemming Principally From the Affordable Care Act (ACA) | 04/04/2011 | 7136 |
| R2181CP | 03/25/2011 | Medicare Claims Processing Pub. 100-04 Chapter 24 Update for HIPAA 5010 and EDI Enhancements | 04/25/2011 | 7269 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R2090CP | 11/10/2010 | Implementation of Errata for Version 5010 of Health Insurance Portability and Accountability Act (HIPAA) Transactions, and Updates in 837I, 837P, and 835 Flat Files | 04/04/2011 | 7202 |
| R2087CP | 11/05/2010 | Implementation of Errata for Version 5010 of Health Insurance Portability and Accountability Act (HIPAA) Transactions, and Updates in 837I, 837P, and 835 Flat Files – Rescinded and replaced by Transmittal 2090 | 04/04/2011 | 7202 |
| R2076CP | 10/28/2010 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process Stemming Principally From the Affordable Care Act (ACA) – Rescinded and replaced by Transmittal 2189 | 04/04/2011 | 7136 |
| R1920CP | 02/19/2010 | Modifications to Gap-Filling Requirements for the Health Insurance Portability Accountability Act (HIPAA) 837 version 5010 Coordination of Benefits (COB) Claims Transactions and National Council for Prescription Drug Programs (NCPDP) Version D.0 Claim Files | 07/06/2010 | 6816 |
| R1844CP | 11/06/2009 | Additional Health Insurance Portability and Accountability Act (HIPAA) 837 5010 Transitional Changes and Further Modifications to the Coordination of Benefits Agreement (COBA) National Crossover Process | 04/05/2010 | 6658 |
| R1841CP | 10/29/2009 | National Council for Prescription Drug Programs (NCPDP) Version D.0. Coordination of Benefits (COB) Requirements for the National Claims Crossover Process | 04/05/2010 | 6664 |
| R1727CP | 05/01/2009 | Coordination of Benefits Agreement (COBA) Repair and Claims Recovery | 10/05/2009 | 6420 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| Requirements Stemming from the Health Insurance Portability and Accountability Act (HIPAA) 5010 Claims Transactions | ||||
| R1720CP | 04/24/2009 | Health Insurance Portability and Accountability Act (HIPAA) American National Standards Institute (ANSI) 837 5010 Coordination of Benefits (COB) Requirements--Part II | 07/06/2009 | 6374 |
| R1704CP | 03/20/2009 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover | 07/06/2009 and 10/05/2009 | 6343 |
| R1640CP | 11/21/2008 | Modifications to the National Coordination of Benefits Agreement (COBA) Process | 04/06/2009 | 6234 |
| R1568CP | 08/01/2008 | Health Insurance Portability and Accountability Act (HIPAA) American National Standards Institute (ANSI) X12-N 837 version 5010 Changes Necessary for Coordination of Benefits (COB) and other Coordination of Benefits Agreement (COBA) Process Revisions | 01/05/2009 | 6103 |
| R1507CP | 05/16/2008 | Coordination of Benefits Agreement (COBA) and Affiliate National Provider Identifier (NPI) Process Modifications | 10/06/2008 | 6024 |
| R1497CP | 05/02/2008 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process | 07/07/2008 | 6037 |
| R1436CP | 02/05/2008 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process – Replaced by Transmittal 1497 | 07/07/2008 | 5866 |
| R1420CP | 01/25/2008 | Clarification Regarding the Coordination of Benefits Agreement (COBA) Medigap Claim-Based Crossover Process | 02/01/2008 | 5837 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R1332CP | 08/31/2007 | Transitioning the Mandatory Medigap (“Claim Based”) Crossover Process to the Coordination of Benefits Contractor (COBC) | 10/01/2007 | 5601 |
| R1296CP | 07/18/2007 | Modifications to the National Coordination of Benefits Agreement (COBA) Crossover Process | 10/01/2007 | 5569 |
| R1282CP | 07/06/2007 | Medicare Contractors Use of the Coordination of Benefits Agreement (COBA) Problem Inquiry Request Form and Send COBA Related Issues to the COB Contractor | 08/06/2007 | 5656 |
| R1242CP | 05/18/2007 | Transitioning the Mandatory Medigap (“Claim Based”) Crossover Process to the Coordination of Benefits Contractor (COBC) | 10/01/2007 | 5601 |
| R1232CP | 04/27/2007 | Modification to the Coordination of Benefits Agreement (COBA) Crossover Process - Replaced by Transmittal 1296 | 10/01/2007 | 5569 |
| R1189CP | 02/28/2007 | Differentiating Mass Adjustments From Other Types of Adjustments and Claims for Crossover Purposes and Revising the Detailed Error Report Special Provider Notification Letters – Replaced by Transmittal 1189 | 07/02/2007 | 5472 |
| R1179CP | 02/02/2007 | Differentiating Mass Adjustments From Other Types of Adjustments and Claims for Crossover Purposes and Revising the Detailed Error Report Special Provider Notification Letters – Replaced by Transmittal 1189 | 07/02/2007 | 5472 |
| R1110CP | 11/09/2006 | Excluding Sanctioned Provider Claims from the Coordination of Benefits Agreements (COBA) Crossover Process | 04/02/2007 | 5353 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R1038CP | 08/25/2006 | COBC Sending Copy of Trading Partner's Eligibility File to Medicare Contractor for Use in Recovery Process | 01/02/2007 | 5250 |
| R1006CP | 07/21/2006 | Modification to the Coordination of Benefits Agreement (COBA) Claims Selection Criteria and File Transfer Protocols | 10/02/2006 | 5094 |
| R967CP | 05/26/2006 | Modification to the Coordination of Benefits Agreement (COBA) Claims Selection Criteria and File Transfer Protocols | 10/02/2006 | 5094 |
| R837CP | 02/03/2006 | Coordination of Benefits Agreement (COBA) Full Claim File Repair Process | 07/03/2006 | 4277 |
| R666CP | 09/02/2005 | Updates to the Coordination of Benefits Contractor (COBC) Detailed Error Report File Layouts | 10/03/2005 | 4042 |
| R586CP | 06/17/2005 | Modification to the National Coordination of Benefits Agreement (COBA) File Transfer and Financial Reporting Processes | 10/03/2005 | 3906 |
| R474CP | 02/11/2005 | Detailed Error Report Notification Process to COBA Partners | 07/05/2005 | 3709 |
| R448CP | 01/21/2005 | Timeframe for Execution of Crossover Agreements and Update on the Transition to the National Coordination of Benefits Agreement (COBA) Program | 02/22/2005 | 3658 |
| R250CP | 07/23/2004 | Update of CWF Procedures | 01/03/2005 | 3404 |
| R158CP | 04/30/2004 | Transition to Medicare Coordination of Benefits Contractor (COBC) | 10/04/2004 | 3273 |
| R138CP | 04/09/2004 | Transition to Medicare Coordination of Benefits Contractor (COBC) | 07/06/2004 | 3218 |
| R098CP | 02/06/2004 | Transition to Medicare Coordination of Benefits Contractor (COBC) | 07/06/2004 | 3109 |
| Rev # | Issue Date | Subject | Impl Date | CR# |
|---|---|---|---|---|
| R001CP | 10/01/2003 | Initial Publication of Manual | NA | NA |
Back to top of Chapter