evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
30.2 - ASC X12 837 Institutional/Form CMS -1450 COB  (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  In accordance with the language provided within 1842(h)(3)(B) of the Social Security Act, no information entered on an incoming Form CMS -1450 or incoming Health Insurance Portability Act (HIPAA) ASC X12 837 institutional claim (current format) shall result in a process whereby CMS transfers the claim to a Medigap insurer.   40 - MSN Messages (Rev.  4069, Issued: 06- 08  18, Effective: 07 - 09- 18, Implementation: 07-  09-18)  A Medicare beneficiary who has a Medigap policy may authorize the participating physician/practitioner or supplier of services to file a claim on his or her behalf and to receive payment directly from the insurer instead of through the beneficiary.  In such cases, Medicare must transfer Medicare claims information to the Medigap insurer.  The Medigap insurer pays the physician/provider/supplier directly.  The Medigap insurer, in turn, reimburses CMSs 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.
(Medicare Claims Processing Manual)
Effective with the future implementation of CMSs 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 C MS-issued Medigap claim -based COBA ID  (ID range 55000 through 55999), which will be assigned by CMSs Benefits Coordination & Recovery Center (BCRC) , if: (1) the physician/practitioner or supplier participates in the Medicare Program; and ( 2) the benefici ary has assigned his/her rights to payment under a Medigap policy to that provider or supplier.   50 - Remittance Notice Messages  (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  All A/B MACs  and  DME MACs shall include the following message on remittance notices sent to participating physicians/practitioners and suppliers when Medigap benefits are assigned and the information in block #9 of the Form CMS -1500 (or FL50 of the Form CMS -1450, as appropriate) is completed:   MA 18  The claim information is also being forwarded to the patients 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   shal l 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.)
(Medicare Claims Processing Manual)
60 - Returned Medigap Notices  (Rev.  4069, Issued: 06- 0818, Effective: 07 -09-18, Implementation: 07-  09-18)   A/B MACs ( Part B) and DME MACs ceased this responsibility on October 1, 2007, when CMSs BCRC assumed full responsibility for the COBA claim- based Medigap process.   70 - Coordination  of Medicare With Medigap and Other Complementary Health Insurance Policies  (Rev. 4069, Issued: 06- 0818, Effective: 07 -09-18, Implementation: 07- 09-18)  For applicable policy on information sharing, see Pub 100- 1, the Medicare General Information, Eligibi lity and Entitlement Manual, Chapter 6.   For applicable cost sharing policy, see Pub 100- 06, the Medicare Financial Management Manual, Chapter 1.    Cost Calculation Process Leading Up to the BCRCs  Assumption of Claim-Based Medigap Crossovers  Up to and including the final claims transferred under their pre-existing mandatory Medigap (claim- based) crossover processes (note:  the final claims should be those processed by the A/B MAC ( Part B) or DME MAC just before the October 2007 release is installed), A/B MACs ( Part B) and DME MACs should determine the frequency at which they routinely transmit notices to all Medigap insurers but must transmit not less often than monthly. (See 70.4)
(Medicare Claims Processing Manual)
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, whic h was inaugurated on October 1, 2007.  (See also Pub.100-04 chapter 27 80.7.)  Following crossover consolidation, all A/B MACs ( Part B) and DME MACs shall continue to pursue collection of unpaid debts from Medigap insurers and other existing trading partners, even after such entities have been transitioned to the COBA process.  Those MACs that maintained claim- based crossover arrangements with Medigap insurers shall pursue collection of their invoices up through and including their invoices for the final claims transfer to the Medigap entities.  These invoices should have been issued no later than one (1) month following the last claims transfer to the Medigap insurers.  Suppression of Sanctioned Provider Claims from Claim- Based Medigap Crossovers   Effectiv e with April 2, 2007, all A/B MACs ( Part B) and DME MACs shall suppress fully denied provider sanctioned claims for their mandatory Medigap crossover process with Medigap insurers, as authorized by 1842(h)(3)(B) of the Social Security Act and 4081(a)(B) of the Omnibus Budget Reconciliation Act of 1987 [Public Law 100-230].  NOTE:   All A/B MACs ( Part B) and DME MACs shall continue to suppress 100 percent paid and 100 percent denied claims from their mandatory Medigap crossovers, per previous CMS guidance.  70.1 - Authorization for Release of Information  (Rev. 2906, Issued: 03- 14-14, Effective: 04-14-14, Implementation 04-14-14)
(Medicare Claims Processing Manual)
See Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual, Chapter 6.  70.1.1 - Requests for Additional Information  (Rev. 2906, Issued: 03- 14-14, Effective: 04-14-14, Implementation 04-14-14)  In the absence of a standing arrangement, the mere presence of an authorization to release and the identification of a complementary insurer on a title XVIII billin g form does not constitute a request for the release of information.  The request for the information must be specific.  70.1.2 - Release of Title XVIII Claims Information for Medigap Insurance Purposes by Providers  (Rev. 2906, Issued: 03- 14-14, Effectiv e: 04 -14-14, Implementation 04-14-14)  Subject to specific written beneficiary authorization, providers, physicians/practitioners, and suppliers are permitted to furnish certain limited information about Medicare eligibility status and related claims information to other payers for complementary insurance purposes.  (See Chapter 6 of Pub 100-01, the Medicare General Information, Eligibility, and Entitlement Manual.)    70.2 - Integration of Title XVIII Claims Processing With Complementary Insurance Claims Processing (Rev. 2906, Issued: 03- 14-14, Effective: 04 -14-14, Implementation 04- 14-14)  General   See Chapter 6 of Pub 100- 01, the Medicare General Information, Eligibility, and Entitlement Manual for instructions about disclosure of information.  See Chapter 1 of Pub. 100- 06, the Medicare Financial Management Manual, for requirements for determining costs.  70.2.1 - Program Recognition  (Rev. 2906, Issued: 03- 14-14, Effective : 04-14-14, Implementation 04- 14-14)  Since title XVIII program identity must be maintained, notices and forms for title XVIII purposes must clearly identify their title XVIII origin.  Also, they must not imply that title XVIII entitlement or enrollment is dependent upon the 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.
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
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
(Medicare Claims Processing Manual)
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).
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
 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).
(Medicare Claims Processing Manual)
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 liab ility indicator field within the HIMR detailed history screens (INPL, OUTL, HHAL, and HOSL), to illustrate the indicator (L or N) that appeared on the incoming HUIP, HUOP, HUHH, or HUHC claim transaction.  CWF Editing for Incorrect Values   If an A/B MAC (Part  A) or A/B MAC (Part  HHH) sends values other than L, N, or space in the newly defined beneficiary liability field in the header of its HUIP, HUOP, HUHH, or HUHC claim, CWF shall reject the claim back to the A/B MAC for correction.  Following rec eipt of the CWF rejection, the A/B MAC (Part  A) and A/B MAC (Part  HHH) shall change the incorrect value placed within the beneficiary liability field and retransmit the claim to CWF.   B.  Developing a Capability to Treat Entry Code 5 and Action Code 3 Claims As Recycled Original Claims For Crossover Purposes  Effective with July 2007, in instances when CWF returns an error code 5600 to an A/B MAC and DME MAC, thereby causing it to reset the claims entry code to 5 and action code to 3, the MAC sha ll 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.
(Medicare Claims Processing Manual)
Upon receipt of a claim that contains entry code 5 or action code 3 with a non- adjustment claim header value of N, the CWF shall treat the claim as if it were an original claim (i.e., as entry code 1 or action code 1) for crossover inclusion or exclusion determinations.  If CWF subsequently determines that the claim meets all other inclusion criteria, it shall mark the claim with an A (claim was selected to be crossed over) crossover disposition indicator.  Following receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) for the recycled claim, the A/B MACs and DME MACs shared systems shall ensure that, as part of their ASC X12 837 flat file creation  processes, they populate the 2300 loop CLM05-3 (Claim Frequency Type Code) segment with a value of 1 (original).  In addition, the A/B MACs and DME MACs shared systems shall ensure that, as part of their ASC X12 837 flat file creation process, they do not create a corresponding 2330 loop REF*T4*Y segment, which typically signifies adjustment.   C.  Developing a Capability to Treat Claims with Non- Adjustment Entry or Action Codes as Adjustment Claims For Crossover Purposes   Effective with July 2007, in instances where A/B MACs and DME MACs must sen d 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.