(Medicare Claims Processing Manual)

5. Create procedure modifier count (458-SE) based upon claim adjudication.  6. Create procedure modifier code as appropriate.   7. Map 442-E7 and 426-E1 as required, without gap- filling.    8. Create 456 -EN, 420- DK, 308 -C8, and 429- DT to the COB file if received on the incoming claim.   9. Map 454-EK (now required in certain situations) and 600-2B if received on the incoming claim.   10. Do not create 461-EU, 462-EV, 463-EW, 464-EX, 354-NX, 357-NV, 995-E2, 996- G1, and 147-U7 if received on the incoming claim.  11. Always create 391 -MT (Patient Assignment Indicator) on the COB flat file.  (NOTE:  CEDI shall reject NCPDP claims with this element missing at the DME MACs front -end.)  H. Transaction Compound Segment  1. Create all of the following required elements witho ut gap- filling:  447 -EC, 448-ED, 449-EE, 450-EF, 451-EG, 488-RE, and 489- TE.  2. Create the following based upon claims adjudication:  412-DC, 423- DN, 426 - DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480- H9.  3. Create the following if received on the incoming claim:  490 -UE, 362-2G, and 363-2H.  I. Transaction Pricing Segment   1. Create the following required elements without gap -filling:  409 -D9 and 430-DU.  2. Create the following based upon claims adjudication:  412-DC, 423- DN, 426 - DQ, 433-DX, 438-E3, 478-H7, 47-H8, 480- H9.  3. Do not create 482-GE, 483-HE, and 484- JE.  J. Transaction Prior Authorization Segment  - Do not create for COB flat file.   K. Transaction Clinical Segment  1. Create all situational elements indicated only if received.   2. Do not create Transaction Additional Doc segment or Additional Documentation Type ID (369- 2Q), as they relate to passage of CMN information, which is no longer supported.  L. Transaction Facility Segment   Create associated elements only if received; otherwise, do not attempt to gap- fill.  M. Narrative Segment.   Create the 390 -BM (Narrative Message) element only if information is populated on the inbound NCPDP new version batch claim.  III. NCPDP New Version Gap -Filling Requirements   The DME MAC shared system shall observe the following gap-filling requirements when creating NCPDP new version COB flat files for transmission to the BCRC:   A. For rare instances where there is not a valid base 5 -byte zip code available to populate a required zip code field, VMS shall populate 96941 within the field corresponding to that segment on the NCPDP new version COB flat file.  B. With respect to element 322 -CM (Transmission Patient Segment), when the DME MACs internal beneficiary eligibility record contains blank or incomplete line -1 street address information, VMS shall populate this element with an initial X followed by 29 spaces.  C. The shared system shall continue the practice of gap -filling element 453 -EJ (Originally Prescribed Product/Service ID Qualifier) when element 445 -EA (Originally Prescribed Product Service Code) is gap- filled with spaces.   D. The shared system shall continue the practice of gap -filling 446-EB (Originally Prescribed Quantity) when the value for this element from the inbound claim is present but non- numeric.   E. For skinny processing, the shared system shall initialize elements 498-PM, 364-2J, 365-2K, 366-2M, 367- 2N to spaces as a gap -fill measure.   F. For skinny processing, the shared system shall initialize element 368- 2P to zeroes as a gap -fill measure.   G. If element 427 -DR (Prescriber Last Name) cannot be found within the DME MACs internal supplier files, the shared system shall set element 427 -DR to Unknown.  SPECIAL NOTE:  When DME MACs encounter particular gap -filling scenarios that are not specifically addressed above, their shared system shall deploy the current gap -fill requirements for the creation of required NCPDP current, in use version COB flat file data content whe n creating NCPDP new version COB flat files for transmission to the BCRC.    IV. Medigap Claim- Based Crossover Processes Involving NCPDP New Version Claims   In advance of their acceptance of incoming NCPDP new version claims, all DME MACs shall inform their affiliate participating suppliers that they may initiate Medigap claim-based crossover processes by taking the following steps:    Continue to enter the Medigap claim-based COBA ID (range 55000 to 59999) in the existing 301-C1 (Group ID) portion of the Transmission Insurance Segment; and    Now report the beneficiarys Medigap policy number in the newly developed 359-2A (Medigap ID) portion of the Transmission Claim Segment.  V. DME MAC NCPDP New Version Cut -Over Requirements   The BCRC  shall effectuate cut -over of COBA trading partners to the NCPDP new claim format through actions taken via the COIF.  Upon receipt of a CWF BOI reply trailer (29) that contains a P NCPDP new version indicator and  an N current, in -use (or old version) NCPDP format indicator, VMS shall cease creation of NCPDP current, in -use (or old version) full COB claim or NCPDP current, in use (or old version) non- SFR skinny COB claims as well as transmission of these files to the BCRC .  VI. Dual BCRC Detailed Error Reports During The Transitional Period and Accompanying New 222 Errors  During the NCPDP new version transitional period, all DME MACs shall accept and process two BCRC Detailed Error Reports one generated by the BCRC  for claims transmitted by the DME MACs in the current, in-use (or old) version NCPDP COB flat file format, and another generated by the  BCRC  for claims transmitted by the DME MACs in the new version NCPDP COB flat file format.   The DME MAC shared system now accept 2 22 error conditions as part of the BCRC  Detailed Error Report for NCPDP claims, as may be referenced in 70.6.1 of this chapter. In this vein, the DME MAC shared system shall not effectuate changes to expand the error description field portion of the BCRC  NCPDP Detailed Error Report to accommodate receipt of the new 222 errors.   Effective with July 2012, the  BCRC  will return the following new  222 errors to DME MACs via the BCRC NCPDP Detailed Error Reports:    N22230NCPDP current, in use or old version production claim received, but the COBA trading partner is  not accepting that version NCPDP production claims;     N22231Current, in use or old version NCPDP test claim received, but the COBA trading partner is not  accepting that  version NCPDP tes t claims;    N22232NCPDP new version production claim received,  but the COBA trading partner is not accepting NCPDP new version production claims; and   N22233NCPDP new version test claims received, but the COBA trading partner is not accepting new version NCPDP test claims.   IMPORTANT:   The BCRC shall not begin applying 222 editing to incoming claims until 14 calendar days after a COBA trading partners production cut-over to the NCPDP new version format have elapsed.  The DME MACs shall not at tempt to repair claims that the BCRC returns via the BCRC Error Reports with error codes N22230 through N22233, regardless of error percentage.  All DME MACs shall create special provider letters to their affiliate supplier, in accordance with 70.6.1 of this chapter, for production claims with error codes N22230 or N22232.  VII.  NCPDP New Version Claims Repair Processes   The DME MACs, working with their shared system, shall initiate new version NCPDP COB claims repair actions when:  1) the error percentage for 333 errors equals or exceeds four (4) percent; and 2) they receive even one (1) 111 error as noted on the BCRC Detailed Error Reports.   As part of their process to initiate a claims repair, the DME MACs shall alert their shared system or Data Center, as per established protocol.  The DME MACs shall also suppress generation of their provider notification letters, in accordance with 70.6.1 of this chapter, for up to 14 days.  If the DME MACs determine that the timeframes for effectuating claim repairs for 111 or 333 errors fall outside of acceptable CMS parameters (e.g., will take 30-60 days or longer) or if the  volume of affected claims is low (1,000 claims or less per week), the DME MACs shall allow for the release of their special provider notification letters to affected suppliers.  Any DME MACs that wish to effectuate a repair of NCPDP production claims whose error percentage falls below four (4) percent shall contact a member of the CMS COBA team before attempting that action.  As a rule, CMS will grant approval for such a repair if the volume of errored claims justifies that action and if the time frame f or repair is acceptable.   While DME MACs will not be expected to initiate the repair of test NCPDP claims, they shall continue to:  1) 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.    IMPORTANT:   The DME MAC shared system shall apply NCPDP non- SFR skinny logic to claim repair situations where they originally transmitted claims to the BCRC prior to January 1, 2012, in the NCPDP prior version claim format.   80 - Electronic Transmission - General Requirements  (Rev. 4069, Issued: 06- 08-18, Effective: 07 -09-18, Implementation: 07- 09-18)  The outbound COB transaction is a post -adjudicative transaction. This transaction inclu des the incoming claim data as well as the COB data. A/B MACs or DME MACs are required to receive all possible data on the incoming 837, although they do not have to process non- Medicare data. However, the shared system must store that data in a store-and-forward repository (SFR). This repository file is designed and maintained by the shared system. This data must be re -associated with the Medicare claim and payment data in order to create a compliant outbound COB transaction using the Medicare Claim/COB flat file as input. The shared system is to use post -adjudicative Medicare data (data used from history and reference files to adjudicate the claim) instead of data received when building the outbound COB transaction. This is to show any changes in data elem ent values as a result of claims adjudication. The shared system must retain the data in the SFR for a minimum of six months.  The Medicare Claim/COB flat file is the format to be used to re -associate all data required to map to the COB transaction.   Data on claims that the A/B MAC or DME MAC receives from its keyshop or image processing systems may not be included on the SFR, depending on the shared system design. The A/B MAC and DME MAC will create the Medicare claim/COB flat file using data available fr om claims history and reference files. Since some data will not be available on these paper claims, the outbound COB transaction will be built as a minimum dataset.  It will contain all required COB transactions segments and post-adjudicative Medicar e data.    The steps from receipt of the incoming claim to creation of the outbound COB are summarized below:    A/B MACs and DME MACs translators perform syntax edits and map incoming claim data to the ASC X12 flat file;   Standard system creates any Medicare edits for the flat file data;    Medicare data on ASC X12 flat file is mapped to the core system;   NOTE: There are no changes in core system data fields or field sizes.