(Medicare Claims Processing Manual)

6. Preparation and Transmission Requirement s  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 recove red claims to the CMS BDC (which, in turn, transmits the files to the COB&R system in support of the BCRC), the VDCs shall transmit the claims  via a separate ASC X12 837 flat file transmission using the modified EFT dataset names shown below.   P/T#EFT.ON.C OBA.PA.Cxxxxx.RCV.Dyymmdd.Thhmmsst   [For 837 Institutional Claims]   P/T#EFT.ON.COBA.PB.Cxxxxx.RCV.Dyymmdd.Thhmmsst  [For 837 non- DMEPOS Professional Claims]   Note the following definitions apply to the dataset names above:    P/T  P = Production; T=Test   Cxxxxx = C + the 5 -digit MAC ID; e.g, C12302   Dyymmdd.Thhmmsst = Current date and Time concatenated to literals D and T.   The VDCs shall send no more than 100,000 recovered claims (which equates to 20 ST -SE envelopes per A/B MAC with 5 ,000 claims per envelope) to the COB&R system supporting the  BCRC per transmission.   7. Marking Claims History To Assist Customer Service Efforts   When the VDC transmits the recovered claims to the COB&R system supporting the  BCRC, the A/B MAC shall mark its claims history to indicate that each claim was recovered and transmitted to the BCRC to be crossed over to the COBA trading partner.   A/B MACs shall notify their customer service representatives that they will be able to d etermine that recovered claims were sent to the BCRC by referencing claims history.  8.         BCRC Detailed Error Report Processes In Relation to the Claims Recovery Process   If A/B MACs receive BCRC Detailed Error Reports that contain a 22 -byte BHT -03 identifier that ends with an R, they shall suppress generation of provider letters, regardless of the error source code indicated (111, 222, or 333).   When the A/B MAC, or its shared system, receives BCRC Detailed Error Reports for recovered BCRC Detailed Error Reports for recovered claims that contain 111, 222, or 333 errors, it shall mark its claims history to indicate that the recovered claims will not be crossed over.   9. The Possibility of Repairing COBA Recovery Claims   A/B MACs, and their shared systems, shall assume that recovered claims for COBA production trading partners that exceed established percentage parameters for 111, 222, and 333 errors are potential candidates for the COBA repair process, as provided in  70.6.2 of this chapter.  In accordance with the full claim file repair process discussed in 70.6.2 of this chapter, A/B MACs and their shared systems shall populate an 18 Beginning of the Hierarchical Transmission (BHT) -02 transaction set purpose code at the ST -SE envelope level when transmitting the repaired COBA recovery claims.   Unlike the process documented in 70.6.2 of this chapter, A/B MACs shall transmit repaired COBA recovery claims to the COB&R system supporting the BCRC via the separate A SC 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 l etters if they, in conjunction with CMS, determine that the recovered claims that contained severe errors cannot be repaired.   10.     COBA Claims Recovery Financial Management Processes   The CMS will reimburse the A/B MAC for individual claims accepted by  the trading partner at the current per claim rate.   The A/B MACs shared systems shall develop a separate report for their associated A/B MACs to enable them to fulfill the foregoing requirements.  The shared systems shall create reports that will provid e MACs with the count of recovered claims per cycle.    Attachments A and B Relating to the COBA Claims Recovery Process   Special note:   With the modernization of the Electronic Files Transfer (EFT) process used for COBA, the A/B MACs and their associated VDCs will no longer need to complete the Electronic Transmittal Form (Attachment) A, as included below, prior to initiating a COBA clai ms recovery process effective April 5, 2021.                                      Attachment A  ELECTRONIC TRANSMITTAL FORM Project:  Coordination of Benefits Agreement (COBA)  Task:  COBA Claims Recovery Process  Contact Information  Company Name:  __________________________   Contact Name:  ______________________________ Phone# ___________  ext. _   Contact Email Address: ______________________________________________  CMSNet Information   Account ID:  __________________  Node ID:  ________________  IP Address:  __________________  Port:  __________________   Production Requirements  Filename(s):  _______________________________________________________  Special Instructions (e.g., file triggers):  Test Requirements  Filename(s):  Special Instructions (e.g., file triggers):                      Attachment B   COBA Eligibility File   Table 1: COBA Eligibility E01 Record Layout Header  E00 Data Element  Description  Field  Length MO Field  Location HEADER RECORD  TYPE  Value -E00 3X O E00.001  HEADER COBA ID  COBA ID assigned by the COBC Field is 9 position, alphanumeric (no special characters), left justified, last four positions are spaces.   Mandatory.  9X O E00.002  HEADER CREATION DATE  Date the record was created; format: (CCYYMMDD), with no special characters  8X O E00.003  HEADER BENEFICIARY STATE CODE  Beneficiary State of residence NOTE: This field will not be used by the COBA Process.  2X O E00.004  FILLER  Blank Field. Value is spaces.  178X  O E00.005   Table 2: COBA Eligibility E01 Record Layout  File attributes:  Format: Fixed block  Length: 200 bytes  Data Field  Length  Type  Displacement  Description  Record type  3 Alpha -Numeric  13 Type of Record Set to E01. Mandatory  COBA ID  9 Alpha -Numeric  4-12 Coordination of Benefits Agreement Identification Number Field is 9 position, alphanumeric (no special characters), left justified, last four positions are spaces.  Mandatory  File Effective Date  8 Alpha -Numeric  13-20 Effective date of file in CCYYMMDD format with no special characters.  Mandatory     Data Field  Length  Type  Displacement  Description  File Update Indicator  1 Alpha -Numeric  21 Type of update values:  A = Add  C = Change/Update  D = Delete  Required as of March 1, 2007  *Beneficiary Surname 20 Alpha- Numeric  22-41 Beneficiary last name  Mandatory  Uppercase characters only  *Beneficiary First  12 Alpha- Numeric  42-53 Beneficiary first name.  Mandatory  Uppercase characters only  Beneficiary Middle Initial  1 Alpha- Numeric  54 Beneficiary middle initial.  Optional  Uppercase characters only  *Beneficiary Birth Date  8 Alpha- Numeric  55-62 Beneficiary date of birth in CCYYMMDD format with no special characters.  Mandatory  *Beneficiary Sex Code  1 Alpha- Numeric  63 Beneficiary sex code values are: M = Male F = Female NOTE: If unknown, default to M Mandatory  Uppercase characters only  Beneficiary Medicare ID 12 Alpha- Numeric  64-75 Beneficiary Medicare ID (Medicare Health Insurance Claim Number [HICN] or Medicare Beneficiary Identifier [MBI]).  Mandatory  Beneficiary  Supplemental ID Number  25 Alpha- Numeric  76-100 Supplemental ID on file with sender. Should be the same as what is submitted on the claim.  Optional  Beneficiary Group Policy Number  20 Alpha- Numeric  101-120 Supplemental policy number on file. Should be the same as what is submitted on the claim.  Optional   Beneficiary Supplemental Eligibility From Date -1 8 Alpha- Numeric  121-128 Medicare supplemental from date in CCYYMMDD format with no special characters.  Mandatory      Data Field  Length  Type  Displacement  Description  Beneficiary Supplemental Eligibility To Date -1 8 Alpha -Numeric  129-136 Medicare supplemental to date in CCYYMMDD format with no special characters NOTE: This is the coverage through date. Indicate zeros for open -ended dates.  Mandatory  Filler  64 Alpha - Numeric  137-200 Unused Field  Populate with spaces     Table 3: COBA Eligibility E01 Record Layout Trailer Record  E99 Data Element  Description  Field  Length MO Field  Location Record Type  Value is 'E99'.  3X M E99.001  E01 Record Count  Total number of E01 records in this file.  7N M E99.002  Filler  Blank Field  Value is spaces  190X  M E99.003     70.6.5 - Coordination of Benefits Agreement (COBA) ASC X12 837 Coordination of Benefits (COB) Mapping Requirements as of July 2012  (Rev. 4281, Issued: 04-  19-19, Effective: 05 -20-19, Implementation: 05- 20-19)  The term Medicare beneficiary identifier (Mbi) is a general term describing a beneficiary's Medicare identification number. For purposes of this manual, Medicare beneficiary identifier references both the Health Insurance Claim Number (HICN) and the Medicare Beneficiary Identifier (MBI) during the new Medic are card transition period and after for certain business areas that will continue to use the HICN as part of their processes.   I. Health Insurance Portability and Accountability Act (HIPAA) 837 current, in use version to HIPAA future version COB Transitional Period Requirements   During the ASC X12 837 transitional period, the shared systems shall accommodate the multi- faceted scenari os that follow below each broad category with respect to creation of ASC X12 837 COB flat files.  INCOMING HIPAA FUTURE VERSION CLAIMS IN ASSOCIATION WITH COBA TRADING PARTNER COB FORMAT SPECIFICATIONS   Scenario 1:  During the ASC X12 837 future version tr ansitional 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 s ubmits 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.