(Medicare Claims Processing Manual)

Subject to specific written beneficiary authorization, providers, physicians/practitioners, and suppliers are permitted to furnish certain limited information about Medicare eligibility status and related claims information to other payers for complementary insurance purposes.  (See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.)    70.2 - Integration of Title XVIII Claims Processing With Complementary Insurance Claims Processing (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  General   See Chapter 6 of Pub 100- 01, the Medicare General Information, Eligibility, and Entitlement Manual for instructions about disclosure of information.  See Chapter 1 of Pub. 100- 06, the Medicare Financial Management Manual, for requirements for determining costs.  70.2.1 - Program Recognition  (Rev. 2906, Issued: 03- 14-14, Effective : 04-14-14, Implementation 04- 14-14)  Since title XVIII program identity must be maintained, notices and forms for title XVIII purposes must clearly identify their title XVIII origin.  Also, they must not imply that title XVIII entitlement or enrollment is dependent upon the individuals retention of his/her complementary insurance policy.   70.2.2 - Records and Information  (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  See chapter 6, of Pub 100- 01, the Medicare General Informat ion, Eligibility, and Entitlement Manual.   70.2.3 - Matching Files Against Medicare Claims Files  (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  See Chapter 6 of Pub 100- 01, the Medicare General Information, Eligibility, and Entitlement Manual.   70.3 - Standard Medicare Charges for COB Records  (Rev.4069, Issued: 06- 0818, Effective: 07 -09-18, Implementation: 07- 09-18)  See chapter 1, of Pub 100- 06, the Medicare Financial Management Manual.   The BCRC  now has exclusive responsibility for the collection and reconciliation of crossover claim fees for those Medigap and non- Medigap claims that A/B MACs and DME MACs send to the BCRC  to be crossed to trading partners.   70.4 - General Guidelines for A/B MAC ( A, B, or HH) or DME MAC Transfer of Claims Information to Medigap Insurers (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  See chapter 1, of Pub 100- 06, the Medicare Financial Management Manual.   70.5 - Audits  (Rev. 2906, Issue d: 03 -14-14, Effective: 04 -14-14, Implementation 04- 14-14)  See chapter 1, of Pub 100- 06, the Medicare Financial Management Manual.      70.6 - Consolidation of the Claims Crossover Process  (Rev. 10638; Issued: 03-09- 21; Effective: 04 -05-21; Implementation: 04-05-21)  The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.  Background  Medicare Claims Crossover Process General   Through the Benefits Coordination & Recovery Center (BCRC), Medicare transmits outbound 837 Coordination of Benefit (COB) and Medigap claims to COB trading partners and Medigap plans, collectively termed trading partners, on a post-adjudicative basis.  This type of transaction, originating at individual A/B MACs and DME MACs following their claims adjudication activities, includes incoming claim data, as modified during adjudication if applicable, as well as payment data.  All A/B MACs and DME MACs are r equired 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 Medic are 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 AS C 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 providers 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 providers 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 providers 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).   BackgroundSpecific COBA Crossover Process   The CMS has streamlined the cl aims 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 CMSs BCRC.  Through the COBA process, each COBA tr ading 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 partners claims selection criteria against processed claims wi th 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, wi ll cross the claims to the COBA trading partner in the HIPAA ASC X12 837 or NCPDP formats, following its validation that the incoming Medicare claims are formatted correctly and pass HIPAA or NCPDP compliance editing.  In addition, CMS shall arrange for the invoicing of COBA trading partners for crossover fees.   For more information regarding the COBA Medigap claim -based crossover process, which was enacted on October 1, 2007, consult 70.6.4 of this chapter.   I.  A/B MAC ( Part A, Part  B, or Part  HHH ) or DME MAC Actions Relating to CWF Claims Crossover Exclusion Logic   A. Determination of Beneficiary Liability for Claims with Denied Services   Effective with the January 2005 release, the A/B MAC (Part  B) and DME MAC shared systems shall include an indicator L (beneficiary is liable for the denied service[s]) or N (beneficiary is not liable for the denied service[s]) in an available field on the HUBC and HUDC queries to CWF for claims on which all line items are denied.  The liability indicators (L or N) shall be reflected at the header or claim level rather than at the line level.   For purposes of applying the liability indicator L or N at the header/claim level and, in turn, including such indicators in the HUBC or HUDC query to CWF, the A/B MAC s (Part  B) and DME MAC shared systems shall follow these business rules:    The L or N indicators are not applied at the header/claim level if any service on the claim is payable by Medicare;    The L indicator is applied at the header/claim level if the ben eficiary is liable for any of the denied services on a fully denied claim; and    The N indicator is applied at the header/claim level if the beneficiary is not liable for all of the denied services on a fully denied claim.   Effective with October 2007, the CWF maintainer shall create a 1 -byte beneficiary liability indicator field within the header of its HUIP, HUOP, HUHH, and HUHC Part A claims transactions (valid values for the field=L, N, or space).    As A/B MACs (Part  A) and A/B MACs (Part  HHH) adjudicate claims and determine that the beneficiary has payment liability for any part of the fully denied services or service lines, they shall set an L indicator within the newly created beneficiary liability field in the header of their HUIP, HUOP , HUHH, and HUHC claims that they transmit to CWF.  In addition, as A/B MACs (Part A) and A/B MACs (Part  HHH) adjudicate claims and determine that the beneficiary has no payment liability for any of the fully denied services or service lines - that is, the  provider must absorb all costs for the fully denied claims - they shall include an N beneficiary indicator within the designated field in the header of their HUIP, HUOP, HUHH, and HUHC claims that they transmit to CWF.  NOTE:  A/B MACs (Part A) and A/B MACs (Part  HHH) shall not set the L or N indicator on partially denied/partially paid claims.   Upon receipt of an HUIP, HUOP, HUHH, or HUHC claim that contains an L or N beneficiary liability indicator, CWF shall read the COBA Insurance File (COIF)  to determine whether the COBA trading partner wishes to receive original fully denied claims with beneficiary liability (crossover indicator G) or without beneficiary liability (crossover indicator F) or adjustment fully denied claims with benefic iary 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).