(Medicare Claims Processing Manual)

B. Repairing 222 and 333 Errors Associated With Production New Version Format Claims   A/B MACs and DME MACs and their shared systems shall repair 222 or 333 errors in association with production new format versi on 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 associat ion 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 att empting 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.   C. Generally Applicable Requirements   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.   D. New Date Parameter Logic and Cutover Claims Repair Requirements   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 forma t.  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.  70.6.3 - Coordination of Benefits Agreement (COBA) Eligibility File Claims Recovery Process  (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 partners 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 partners 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 MACs 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.   1. Receipt and Processing of the BCRC COBA Eligibility File and Searc hing Claims History for the Needed Claims   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 partners 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 recove ry.   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), an d 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 trans mitted 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.   2. Time Frames for Recovery   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.   3. Using Data Elem ents from the COBA Eligibility File For the Claims Recovery Process and Copying Elements from That File to the Recovered Claims Flat File  A/ B MACs shall perform the following activities related to the COBA eligibility file:   a) Utilize each beneficiarys coverage dates from the COBA eligibility files ( file displacement 121128 for beneficiary supplemental eligibility -from date and file displacement 129136 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.   4. Using Data Elements from the COBA Eligibility File For  the Claims Recovery Process and Copying Elements from That File to the Recovered Claims Flat File   A/ B MACs shall perform the following activities related to the COBA eligibility file:   e) Utilize each beneficiarys 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);   f) Apply the specified CWF date span; or   g) Apply the date of service parameters; or   h) 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.  4. Scope of the Claims Recovery Effort  Neither the A/B MAC nor its VDC shall be required to search archived claims history while fulfilling the COBA eli gibility file claims recovery process.   The A/ B MAC and its VDC shall not be required to apply the COBA production trading partners 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) indicat or in relation to the processed claims.   5. Populating a Unique BHT -03 Identifier to Designate Recovered 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.)   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]