evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
For N301:   The A/B MAC (B) shared system shall map Xs to the minimum  standard required for the field.    For N401N403:  The A/B MAC (B) shared system shall undertake the following actions:   N401 (City)populate Cityville;  N402 (State Code)populate MD; and  N403 (Postal Zone/ZIP Code)populate 96941.  8b. In addition, the A/B MAC (B) shared system shall gap-fill the required +4 component of ZIP code (N403 segment) with 9998 only in association with loops 2010AA, 2310C, and 2420C.  9. The shared system shall map UN in the ASC X12 837 new version COB flat f ile field that corresponds to loop 2410 (CTP) and segment CPT04 only when the 2410 (CTP) CTP04 segment is either blank or contains a non-valid value.  10. The shared system shall apply the gap-fill value X to the field corresponding to loop 2430 (SVD) and segment SVD03-2 in situations where the value on the incoming claim is either missing or non -valid.  11. The A/B MAC (B) shared system shall discontinue the process of gap- filling diagnosis code information within loop 2300 HI in association with ambulance claims that ambulance suppliers file to Medicare on paper.   12a. Following adjudication of both electronic and paper billed claims, the shared system shall discontinue the practice of applying gap- fill values of all 9s within the ASC X12 837 new version COB flat file field that corresponds to 2410 LIN03 if the incoming claim contains an incomplete or non-valid national drug code (NDC).  If an incoming paper claim contains a syntactically non- valid NDC code that the A/B MAC (B) or DME MAC subsequently keys, the shared system shall not attempt to gap -fill the field that corresponds to 2410 LIN03 on the ASC X12 837 new version COB flat file.
(Medicare Claims Processing Manual)
12b. The DME MAC shared system shall gap -fill the loop 2430 (SVD) SVD03-2 segment with S5000 or S5001, as appropriate, in situations where the incoming claim contains an NDC within the 2410 LIN02 that does not correspond to a HCPCS on the NDC/HCPCS crosswalk.   13. If the incoming claim is paper and A/B MAC or DME MACs internal provider file contains incomplete information necessary to populate the 2310C loop (in cases where required), the shared system shall gap- fill all required segments with Xs.  NOTE:  The shared system shall discontinue the practice of mapping submitted but not forwarded as a gap -fill convention in this situation for segments where information is required.  14.  If the incoming claim is paper or electronic, the shared system  shall map non-specific procedure code within the ASC X12 837 COB flat file field that corresponds to loop 2400 SV202-7 (non- specific composite medical procedure description) if a non- specific procedure code description is required, as per the Implementation G uide, and the associated procedure code is defined as not otherwise classified.  (See the following link for the latest listing of not otherwise classified procedure codes: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/Alpha- Numeric -HCPCS.html?DLSort=0&DLEntr ies=10&DLPage=1&DLSortDir=descending&DLFilter=NOC    15. The A/B MAC (B) shared system shall utilize the claims earliest service date to satisfy the requirement for 2300 DTP03 (date of admission), where required, in association with claims whose place of service code is 21, 51, or 61.  16. The A/B MAC (B) shared system shall populate 99 as a gap- fill/default value for loop 2300 (CLM) segment CLM05-1 (Facility Type Code) within the corresponding field of the ASC X12 837 ne w version COB flat file.
(Medicare Claims Processing Manual)
17. For ambulance claims, the A/B MAC (B) shared system shall map LB in the ASC X12 837 new version COB flat file field the corresponds to 2400 CR101 if that field would otherwise contain spaces where there is a value (weight) present in 2400 CR102.  18. Also, for ambulance claims, the A/B MAC (B) shared system shall produce spaces in the field that corresponds to loop 2400 CR101 when loop 2400 CR102 on the incoming claim is blank.   19. All shared systems shall not attempt to gap -fill or systems -fill the N4 segment (now situational) within the field corresponding to loop 2330B on the ASC X12 837 COB flat file.  In addition, if information needed to create the N4 segment is available but is incomplete, the shared systems shall not create the loop 2330B N4 segment.  IV. Other ASC X12 837 New Version COB Requirements    A. Complementary Credits   Upon receipt of a Beneficiary Other Insurance (BOI) reply trailer (29) that contains a P ASC X12 837 indicator, the shared systems shall ensure that their affiliate A/B MACs and DME MACs are able to:  1) book complementary credits for the affected claim; and 2) transmit the production claim to the BCRC after it has finalized on the A/B MAC or DME MACs payment floor.  Following receipt of a BOI reply trailer (29) that contains a T ASC X12 837  indicator, as applicable, the shared systems shall ensure that their affiliate MACs:  1) do not anticipate receipt of complementary credits for that version of the claim; and 2) transmit the test claim to the BCRC after it has finalized on the contractors payment floor.   All shared systems shall, in addition, not expect complementary credits in association with their affiliated A/B MAC or DME MACs receipt of a CWF BOI reply trailer (29) that con tains an N new version indicator.  B. BCRC Business- Level Editing of Incoming New Version COB Flat Files
(Medicare Claims Processing Manual)
B. BCRC Business- Level Editing of Incoming New Version COB Flat Files   With the implementation of the new version claim standards, the BCRC will apply business level edits to ensure that incoming claims possess the structure necessary for successful translation into the HIPAA ASC X12 837 new version claim formats.  See 70.6.1.1 of this chapter for charts that define the 111 level errors that the BCRC will return to the A/B MACs or DME MACs when their incoming ASC X12 837 COB flat files cannot be utilized to build compliant outbound ASC X12 837 claim transactions.  70.6.6 - National Council for Prescription Drug Programs (NCPDP) Version D.0 Coordination of Benefits (COB) Requirements  (Rev. 4281, Issued: 04- 19-19, Effec tive: 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 Medicare card transition period and after for certain business areas that will continue to use the HICN as part of their processes.   I - BASIC REQUIREMENTS   Prior to the mandatory cut- over to the NCPDP new batch telecommunications claim version, the DME MAC shared system shall develop a current, in-use format skinny non-SFR claim format to accommodate those situations where COBA trading partners are unable to accept pharmacy -submitted claims in the NCPDP new version format.  In addition, the DME MAC shared system shall develop an NCPDP new version skinny non-SFR format that addresses the scenario of claims originally adjudicated in the  NCPDP current, in- use format and later adjusted after the NCPDP new version format is required in association with all incoming and outgoing NCPDP new version claims.
(Medicare Claims Processing Manual)
The DME MAC shared system shall also develop an NCPDP new version skinny non-SFR forma t that addresses the scenario of claims that a DME MAC originally adjudicated in the NCPDP current, in-use format but suspended for a period of time that meets or transcends the date by which the NCPDP new version format is required in association with all incoming and outgoing NCPDP new version claims.  II - NCPDP New Version  Mapping Requirements   With respect to the NCPDP new version COB flat file submissions to the Benefits Coordination & Recovery Center (BCRC), the ViPS Medicare System (VMS) maintainer shall observe the following business rules for mapping:  A. General   1. The 504-F4 (Message) Trailer portion of the file shall contain a 22-byte identifier populated as follows:  a.) Bytes 1 -9Contractor ID (9 bytes; DME MAC ID, or, 5 bytes left justified, followed by spaces);  b.) Bytes 10-14Julian Date (5 bytes, expressed as YYDDD);   c.) Bytes 15-19Sequence Number (5 bytes, starting with 00001; should increment for each ST -SE envelope);  d.) Bytes 20-21Claim Version Indicator (2 bytes; values= 20 for NCPDP version D.0 claims); and   e.) Byte 22Test/Production Indicator (1 byte; valid values=Ttest; P production).  B. Transmission/Transaction Header Segment   1. Create 101 -A1 (BIN assigned number) with spaces.   2. Create the claim version release number (102 -A2) within the Transmission/Transaction Header Segment.   3. Populate the appropriate transaction code (103-A3), the processor control number (104-A1), and transaction count value (109- A9).  4. Always map the service provider ID qualifier corresponding to the national provider identifier (NPI) in 202-B2.   5. Always map the suppliers NPI in 201- B1 (Service Provider ID).   6. Map date of service from incoming claim for 401- D1.  7. Map 110- AK (Software Vendor/Certification ID) from incoming claim.
(Medicare Claims Processing Manual)
6. Map date of service from incoming claim for 401- D1.  7. Map 110- AK (Software Vendor/Certification ID) from incoming claim.   IMPORTANT:    For skinny NCPDP current, in use claim scenarios, where the incoming claim is the current, in use version NCPDP, the shared system shall map unknown in 110- AK.  C. Trans mission Insurance Segment   1. Map the beneficiarys Medicare beneficiary identifier  in 302-C2 (Cardholder ID).   2. Map 312-CC and 313-CD (Cardholders First and Last Names) using information from the DME MACs internal eligibility file.   3. Do not cre ate 301 -C1 (Group ID), as CMS no longer authorizes claims- based transfers to Medicaid State Agencies.   4. Do not create 336-8C (Facility ID), even in skinny claim situations.  5. For Medigap claim -based crossover purposes only, the shared system shal l continue to populate the Medigap claim-based COBA ID (range 55000-55999) in the flat file field corresponding to 301-C1 (Group ID), as derived from the incoming claim.   In addition, the shared system shall populate the Medigap policy ID in the newly cre ated 359-2A (Medigap ID) element, as derived from the incoming claim.   6. Always map an A value for element 361 -2D (Provider Accept Assignment Indicator).   7. Do not  create elements 115 -N5, 116-N6, 314- CE, 303-C3, and 306-C6.   8. Create 524 -F0 (Plan ID) in the future only when CMS directs.  D. Transmission Patient Segment   1. Create element 331 -CX (Patient ID Qualifier) as appropriate.   2. Create 307 -C7 (Place o f Service) based upon the incoming claim.   3. Always map the beneficiarys Medicare beneficiary identifier in 332- CY (Patient ID).
(Medicare Claims Processing Manual)
3. Always map the beneficiarys Medicare beneficiary identifier in 332- CY (Patient ID).    4. Map elements 304 -C4, 305-C5, 310-CA, and 311- CB from the DME MACs internal beneficiary eligibility file.   5. Map el ements 322- CM, 323-CN, 324-CO, and 325- CP from the DME MACs internal beneficiary eligibility file.   (* --See Gap Filling Requirements in Attachment B to address situations where the beneficiarys line -1 address, as derived from the DME MACs internal bene ficiary eligibility file, is blank or incomplete.)  6. Map 326-CQ (Patient Phone Number) and 350- HN (Patient E -mail Address) from incoming claim.  ( Assumption:   CEDI will ensure these values are syntactically correct as a condition of inbound claim acceptance.)   7. Do not create element 335 -2C (Pregnancy Indicator) on the NCPDP new version COB file.  E. Transaction Prescriber Segment   1. Map element 466 -EZ (Prescriber ID Qualifier) from the incoming claim.   2. Always map 01 for element 468- 2E (Primary Care Provider ID Qualifier).   3. Map the NPI, as derived from the incoming claim, in element 421- DL (Primary Care Provider ID).   4. Map the suppliers name, as derived from the DME MACs internal provider files, for 470- 4E (Primary Care Provider Last Name).   5. Map 411- DB based upon adjudicated claim data.   6. Map 427- DR (Prescriber Last Name) and 364 -2J (Prescriber First Name) from the DME MACs internal supplier files.
(Medicare Claims Processing Manual)
6. Map 427- DR (Prescriber Last Name) and 364 -2J (Prescriber First Name) from the DME MACs internal supplier files.   7. Map 365- 2K (Prescriber Address), 366 -2M (Prescriber Ci ty), 367- 2N (Prescriber State), 368 -2P (Prescriber Zip), and 498- PM (Prescriber Phone Number) based upon the availability of these elements in the SFR.  (See Attachment B for special gap -filling requirements that will come into play for NCPDP skinny mapping.)  F. Transaction COB/Other Payments Segment   1. Map element 337 -4C from the incoming claim.    2. Prepare element 338 -5C to appropriately qualify deductible or co-insurance remaining.  (NOTE:  In the case of adjustment claims, where the DME MAC used 98 or 99 previously, the shared system shall populate the NCPDP new version equivalent qualifying value on the COB flat file.)  3. Map value 05 for element 339 -6C in relation to Medicares role as payer of the claim.   4. Map the DME MACs workload identifier (e.g., 16003) in element 340-7C.  5. Map the Internal Control Number (element 993-A7) as received from CEDI and as a result of claim adjudication.   6. Map the following out on the COB flat file only if received on the incoming claim:  4 43-E8, 341- HB, 342-HC, 431-DV, 471-5E, 472- 6E.  7. Create 353 -NR, 351-NP, and 352-NQ in terms of primary payers patient responsibility count, qualifier, and remaining amount, as applicable, or the patient responsibility count, qualifier, and remaining amount after Medicare.   8. Do not map 392-MU, 393-MV, and 394- MW, as these are not used for Medicare purposes.   9. Do not create any portion of the Transaction Workers Compensation Segment.  G. Transaction Claim Segment
(Medicare Claims Processing Manual)
8. Do not map 392-MU, 393-MV, and 394- MW, as these are not used for Medicare purposes.   9. Do not create any portion of the Transaction Workers Compensation Segment.  G. Transaction Claim Segment   1. Map 343-HD, 344- HF, and 345-HG based upon availability on the data on the incoming claim.   2. Create 455 -EM and 402-D2 as required, without gap- filling.   3. Create 403 -D3, 405- D5, 406-D6, and 407-D7 as required, without gap- filling.   4. Create all of the following if received on the incoming claim:  408-D8, 414- DE, 415-DF, 418-DI, 419-DJ, 420-DK, 453-EJ, 445-EA, 446-EB, and 457- EP. (NOTE:  Gap -filling of 453- EJ with spaces is acceptable if the shared system is also concurrently gap-filling 445- EA with spaces.)   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
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
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.
(Medicare Claims Processing Manual)
 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;
(Medicare Claims Processing Manual)
 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.
(Medicare Claims Processing Manual)
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)