evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
IV. A/B MAC and DME MAC Act ions Relating to the Transition to the ASC X12 837 Version 5010 and NCPDP Version D.O   A.  CWF COIF and BOI Reply Trailer (29) Processes   Effective January 5, 2009, the BCRC , at CMSs direction, created a new 1- byte 5010 Test/Production Indicator and a new 1 -byte NCPDP D.0 Test/Production Indicator on the COBA Insurance File [COIF] (valid values= Nnot 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 N CPDP D.0 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.)   B.  Transmission of the COB Flat File or NCPDP File to the BCRC
(Medicare Claims Processing Manual)
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 sh all 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 s hall 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 Medicares 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 tra nsfer 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
(Medicare Claims Processing Manual)
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.  Flat File Conventions for Transmission to the B CRC For Production COBA Crossover Claims Prior to July 2012
(Medicare Claims Processing Manual)
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:  NM103Use spaces; and  NM109Include 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 segmentFor NM103, NM104, NM105, and NM107, use spaces; NM1 segment For NM109, include beneficiarys Medicare beneficiary identifier ; N3 segmentUse all spaces; and  N4 segmentUse 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.
(Medicare Claims Processing Manual)
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 informati on:  NM103Use spaces; and  NM109Include 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 situa tions.   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 de notes 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 i nformation will be unknown to the standard systems, the following fields should be formatted as follows for the NM1 segment on the100 record:
(Medicare Claims Processing Manual)
NM103Use spaces; and  NM109Include 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 beneficiarys Medicare beneficiary identifier ; N3 segment Use all spaces; and  N4 segment Use all spaces.   The 2010BC loop denote s 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 segmentFor NM103, use spaces; NM1 segmentFor NM109, include COBA ID (5-digit COBA ID picked up from the BOI reply trailer 29);  N3 segment Use all spaces; and  N4 segmentUse 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:  NM103Use spaces; and  NM109Include 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.
(Medicare Claims Processing Manual)
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.  C.  BCRC Processing of COB Flat Files or NCPDP Files   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 valueR).  The VDCs shall be prepared to accept the following modified dataset names effective April 5, 2021:   xxxx.FISP.HBADR.GHI.COB5RESP(+1)  [For 837 institutional claims]  xxxx.MCSP.HBXDR.ADyyCOBC(+1)  [For 837 non-D MEPOS professional claims]   xxxx.VMSP.COBC.A5010.ERROR.RESPONSE(+1)  [For 837 DMEPOS professional claims]  Value is TBD  [For NCPDP Part B Drug Claims]  ( Note:  Since the implementation of NCPDP D.0 COB claims as part of COBA, the VDCs have not been set up t o receive NCPDP Claim Response Files.)   Note the following definitions that apply to the above Claim Response File dataset names:   VDCx= directs the file to the appropriate VDC; VDC1 = CD1.EDC1; VDC3 = CD3.EDC1  xxxx = High -level qualifier (HLQ) identifier currently used by the MAC  yy = identifier currently used by and defined for Part B files for Plan Code
(Medicare Claims Processing Manual)
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 NCP DP 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 returne d 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 ze ro-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.
(Medicare Claims Processing Manual)
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:    P/T#EFT.ON.COBA.Cxxxxx.PARTA.Dyymmdd.Thhmmsst   [For Institutional Claims}   P/T#EFT.ON.COBA.Cxxxxx.PARTB.Dyymmdd.Thhmmsst   [For Professional Claims]   P/T#EFT.ON.COBA.Cxxxxx.NCPDP.Dyymmdd.Thhmmsst   [For NCPDP Part B Drug Claims]  Note the  follo wing definitions that apply to the dataset names above:     P/T= P Production; T= Test   Cxxxxx= C + the 5 -digit MAC ID; e.g., 12302   Dyymmdd.Thhmmsst  = 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 Medicares 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.
(Medicare Claims Processing Manual)
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.  E.  The COBA Medigap Claim-Based Process Involving CWF  Refer to 70.6.4 of this chapter for more information regarding this process.  F.  COBA Customer Service Issues   1.  Customer Service  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 s tandard 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 req uiring 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.                A/B MAC and DME MAC: COBA PROBLEM INQUIRY REQUEST FORM   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 submitters last name, first name)          Date Submitted (Enter current date           MM/DD/YR)  Contact #  (Enter submitters phone #)          E-mail Address  (Enter submitters 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
(Medicare Claims Processing Manual)
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 b eneficiary Medicare beneficiary identifier and the claim ICN/DCN.  BCRC USE ONLY.  Date:                                                                               Ticket #:   V.  Identification of Mass Adjustments for COBA Crossover Purposes   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.  Working Definition of Mass Adjustment
(Medicare Claims Processing Manual)
Working Definition of Mass Adjustment  For COBA crossover purposes, a mass adjustme nt 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.  Inputting a One -Byte Header Value on Claim Transactions to Designate Mass Adjustment and Associated Processes   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 clai ms 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 ad justment 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 s ituation, within the header of the A/B MACs or DME MACs processed claims that they will cable to CWF for verification and validation:  Mif mass adjustment claim tied to an MPFS update; or  Oif mass adjustment claim-other.
(Medicare Claims Processing Manual)
If A/B MACs and DME MACs se nd 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.  VI. Special ASC X12 835 Remittance Advice and MSN Requirements for Health Care Pre- Payment Plans (HCPPs) and Health Ma intenance Organization (HMO) Cost Plans that Receive Crossover Claims   Effective January 5, 2009, at CMSs 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 chapte r 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.)  VII. Special Suppression Requirements for Part A Credit Claim Portion of Debit -Credit Claim Pairing
(Medicare Claims Processing Manual)
VII. Special Suppression Requirements for Part A Credit Claim Portion of Debit -Credit Claim Pairing   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 MACs (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.   70.6.1 - Coordination of Benefits Agreement (COBA) Detailed Error Report Notification Process  (Rev. 11939; Issued:04-05- 23; Effective:07 -06-23, Implemtation:07-06-23)   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 fo r 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 (BCR C) 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.