evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
21. FISS shall always send at least one (1) complete iteration of 2320, 2330A, and 330B on all ASC X12 837 COB flat files.  22a. FISS shall populate the required 2310-A (Attending Provider Name), 2310B (Operating Physician Name), and 2310C (Other Operating Physician Name) NM1 segments, with information derived from the incoming electronic claim.  FISS shall always populate the NM108 segment always indicating XX and shall derive the NPI from the incoming claim.   22b. If the incoming claim is paper or DDE entered, FISS shall derive the attending, operating, and other operating physician name from the Form CMS-1450 claim or DDE entry, or as necessary from the A/B MAC (A or HH)s internal provider files.  FISS shall always populate the NM108 segment with XX and shall derive the NPI from the Form CMS-1450 claim or DDE entry screen.  23. When the incoming claim is paper, Form CMS-1450 or DDE entered, FISS shall continue with all other mapping practices not otherwise addressed above when creating the outbound skinny 837 COB flat file.  [For example, FISS shall continue to derive the discharge hour, admission date/hour, admission source code, medical record number, principal diagnosis, admitting diagnosis code, principal procedure information, occurrence codes, occurrence span codes, value codes, and condition codes from the associated FL fields of the Form CMS -1450 or from the DDE keyed information.]  24. FISS shall migrate the Line Item Control Number data from the Store and Forward Repository (SFR) to the area of the ASC X12 837 COB flat file that  corresponds to loop 2400, REF02, where REF01=6R, as per the Implementation Guide.  25. Upon implementation of the 5010 Errata changes, FISS shall take the following action with respect to the creation of the field corresponding to 2300 CL101 on the 837 COB f lat file as a gap -fill or systems -fill value when necessary:
(Medicare Claims Processing Manual)
Map the value 9 (Information Not Available) to the field corresponding to 2300 CL101 on the ASC X12 837 COB flat file if the incoming claim is received in a claim format other than the new, no w current version, and the CWF BOI reply trailer 29 indicator for the new, now current version returned to the A/B MAC (A or HH) for the claim= T or P.  B. ASC X12  837 Professional COB Claim Mapping Rules  Effective with the testing and implementatio n of the Health Insurance Portability and Accountability Act (HIPAA) ASC X12 837 professional new and now current version, the Multi- Carrier System (MCS, the A/ B MAC (B) shared system) and the ViPS Medicare System (VMS, the DME MAC shared system) shall ob serve the following common business rules for mapping of the new and now current version COB (professional) flat file:    1 The following segments shall not  be passed to the BCRC :  a. ISA (Interchange Control Header Segment); b. IEA (Interchange Control Trailer Segment);  c. GS (Functional Group Header Segment); and d. GE (Functional Group Trailer Segment).   2. The shared system shall map the claim version (new and now current version) in the field of the ASC X12 837 new version COB flat file that corresponds to the ST03 segment.    3. The BHT02 (Beginning of the Hierarchical TransactionTransaction Set Purpose Code) shall be passed either with value 00 or 18 under the following circumstances:   a. Normal claims submission to the BCRC use 00 ; and b. COB A claims repair process use 18.  4. The BHT03 (Beginning of the Hierarchical TransactionReference Identification or Originator Application Transaction ID) shall contain identifiers populated as follows:  a. 23 bytes for non- COBA recovery claims as follo ws:
(Medicare Claims Processing Manual)
4. The BHT03 (Beginning of the Hierarchical TransactionReference Identification or Originator Application Transaction ID) shall contain identifiers populated as follows:  a. 23 bytes for non- COBA recovery claims as follo ws:   Bytes 1 -9A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC or DME MAC ID, or 5 bytes left justified, followed by 4 spaces);  Bytes 10- 14Julian Date (5 bytes, expressed as YYDDD);  Bytes 15- 19Sequence Number (5 bytes, starting with 00001; should increment for each ST -SE envelope);  Bytes 20- 21Claim Version Indicator (2 bytes; values=50 for 5010 claims); and Byte 22Test/Production Indicator (1 byte; valid values=T test; P production); and  Byte 23Original versus Adjustment Claim Indicator (1 b yte)-Valid Values are:  Efor re processe d claims that for merly included an electronic  prescribing (e-RX) negative adjust ment amount;  Ofor original claims; P for Affordable Care Act or other congressional imperative mass adjustments; Mfor non- Affordable Care Act mass adjustments tied to Medicare Physician Fee Schedule (MPFS);  Sfor mass adjustment claims all others; Rfor RAC adjustment claims; and  Afor routine adjustment claims, not previously classified.  Additionally, as of April 7, 2014:  C  for CMS -directed mass adjustment action (use specified by CMS);  Vfor void/cancel only claim   b. 23 bytes for COBA recovery claims as follows:
(Medicare Claims Processing Manual)
b. 23 bytes for COBA recovery claims as follows:   Bytes 1 -9A/B MAC (B) or DME MAC ID (9 bytes; A/B MAC (B) or DME MAC ID, left justified, or 5 bytes followed by 4 spaces);  Bytes 10- 14Julian Date (5 bytes, expressed as YYDDD);  Bytes 15- 19Sequence Number (5 bytes, starting with 00001; should increment for each ST -SE envelope);  Bytes 20- 21Claim Version Indicator (2 bytes; values=50 for 5010 c laims); and  Byte 22COBA recovery indicator (1 byte; indicator =R)  Byte 23Original versus Adjustment Claim Indicator (1 byte)   (NOTE:  See II.B.4.a directly above for valid values.)   5. The 1000- A PER (Submitter EDI Contact Information) shall be populate d as follows:   a. PER01 populate 1C;  b. PER02 populate BCRC EDI Department;  c. PER03 populate TE; and  d. PER04 populate 6464586740.   6. The 1000- B loop NM1 (Receiver Name) denotes the crossover trading partner.  If the A/B MAC (B) or DME MAC receives multiple COBA IDs via the BOI reply  trailer (29), the shared system shall submit a separate ASC X12 837 transaction for each COBA ID received .  Since crossover trading partner information will be unknown to the shared systems, the shared system shall format the following fields as indicated:   a. NM101populate 40; b. NM102populate 2; c. NM103populate spaces; d. NM108populate 46; and e. NM109include COBA ID (5 -digit COBA ID obtained from the BOI reply trailer 29).
(Medicare Claims Processing Manual)
7a. For all 2000A, 2310B, and 2420A PRV (Billing Provider Specialty Information) segments, the A/B MAC ( B) and DME MAC shared systems shall map the taxonomy code values reported in PRV01 through PRV03 on the incoming electronic claim to the corresponding fields within the ASC X12 837 COB flat file.  If the values reported for these loops on the incoming claim are incomplete or syntactically incorrect, the shared system shall not create the loop and associated segments.   7b. The A/B MAC (B) shared system shall continue the practice of only mapping 2420A- level PRV segments if the incoming electronic claim is multi- line, with differing rendering physicians associated to each line.  The A/B MAC ( B) shared system shall not map a 2420A-level reported PRV segment if the incoming electronic claim contains a single detail line.   8. The A/B MAC (B) and DME MAC shared systems shall derive information for 2010AA PER 03, PER04, PER05, and PER06 if such information is present and syntactically complete within the A/B MAC (B) or DME MACs internal provider files.  If such information is unavailable or incomplete, the affected shared systems shall not create the 2010AA PER loop on the ASC X12 837 new version professional COB flat file.  9. The A/B MAC (B) and DME MAC shared systems shall derive all provider specific information necessary to populate the NM1 and N3 and N4 segments of such loops as 2010AA, 2010AB, and 2310B from each A/B MAC (B) or DME MACs  internal provider files.  In addition, where a providers tax ID is required within a secondary REF segment, the shared systems shall also derive this information from each A/B MAC (B) or DME MACs internal provider files.  10a. For 2320 SBR01, in situations where there is only one (1) payer that is primary to Medicare, VMS shall apply P to any payer that is primary before Medicare; S for Medicare as the secondary payer; and U for all supplemental payers after Medicare.
(Medicare Claims Processing Manual)
S PECIAL NOTE:  I f, for example, a claim contains at least two (2) primary payers before Medicare, the DME MAC shared system shall reflect the primary payer as 2320 SBR01as P; the secondary payer as 2320 SBR01 = S; and, the tertiary payer, Medicare, as 2320 SBR01 = T.  MCS shall reflect all additional supplemental payers as 2320 SBR01 = U.  10b. For 2000B SBR01 (element 1138), the shared system shall apply P when Medicare is the primary payer and shall apply U for all other supplemental payers after Medicare.   11. For additional 2000B requirements, the shared system shall take the following actions:   a. SBR03 map spaces; and  b. SBR09 If the COBA ID returned via the BOI reply trailer (29)=70000-79999, map MC; for all other COBA IDs, map  CI.  12. The 2010BA loop denotes beneficiary subscriber information.  There are two (2) crossover scenarios to address:  regular, eligibility file -based crossover, and Medigap claim -based crossover.    (1)  For regular eligibility file -based crossover (COBA ID=anything except 55000 through 59999), the shared system shall populate the NM1, N3, and N4 segments as follows:    2010BA NM1Subscriber Name:   a. NM101popula te IL;  b. NM102populate 1; c. NM103derive from internal beneficiary eligibility file; d. NM104derive from internal beneficiary eligibility file; e. NM105derive from internal beneficiary eligibility file if available;    otherwise populate spaces;  f. NM108populate MI; and  g. NM109populate the beneficiarys Medicare beneficiary identifier .  2010BA  N3Subscriber Address:   a. N301derive from internal beneficiary eligibility file; and  b. N302derive, as necessary, from internal beneficiary  eligibility file; otherwise populate spaces.
(Medicare Claims Processing Manual)
a. N301derive from internal beneficiary eligibility file; and  b. N302derive, as necessary, from internal beneficiary  eligibility file; otherwise populate spaces.  2010BA N4Subscriber City/State/ZIP Code:   a. N401derive from internal beneficiary eligibility file; b. N402derive from internal beneficiary eligibility file;  c. N403derive from internal beneficiary eligibi lity file; and  d. N407derive if available and applicable from internal beneficiary eligibility file; otherwise populate spaces.  NOTE :   See G ap-Fill section for the valu es to be  populated on outbound C OBA crosso ver claims when the individual data conte nt for N401 (City) or N402 ( State) or N403(Zip/Postal Code) cannot othe rwise  be d erived.    (2) Medigap claim -based crossover (COBA ID=55000 through 59999 only), the shared system shall populate the NM1, N3, and N4 segments as follows:    2010BA NM1Subscriber Name:   a. NM101populate IL; b. NM102populate 1; c. NM103derive from internal beneficiary eligibility file; d. NM104derive from internal beneficiary eligibility file; e. NM105derive from internal beneficiary eligibility file if  available; otherwise populate spaces; f. M108populate MI; and g. M109populate beneficiary policy number as derived from Item 9- D of Form CMS -1500 claim or 2330B NM109 of the incoming 837 professional claim.  The shared system shall only populate the beneficiarys Medicare beneficiary identifier here if the policy number is unavailable on the incoming claim.   2010BA N3Subscriber Address:   a. N301derive from internal beneficiary eligibility file; b. N302derive, as necessary, from internal beneficiary eligibility file; otherwise populate spaces.   2010BA N4Subscriber City/State/ZIP Code:
(Medicare Claims Processing Manual)
2010BA N4Subscriber City/State/ZIP Code:   a. N401derive from internal beneficiary eligibility file; b N402derive from internal beneficiary eligibility file; c. N403derive from internal benefici ary eligibility file; and  d. N407derive, if available, from internal beneficiary eligibility file; otherwise populate spaces. NOTE :   See G ap-Fill section for the valu es to be  populated on outbound C OBA crosso ver claims when the individual data conte nt for N401 (City) or N402 ( State) or N403 (Zip/Postal Code) cannot othe rwise  be d erived.   13. The shared system shall populate the 2330A (Other Subscriber) NM1, N3, and N4 segments as follows:     2330ANM1:    a. NM101populate IL; b. NM102populate 1; c. NM103derive from internal beneficiary eligibility file; d. NM104derive from internal beneficiary eligibility file; e. NM105derive from internal beneficiary eligibility file if available; otherwise populate spaces; f. NM108populate MI; and  g. NM109populate the beneficiarys Medicare beneficiary identifier.    2330A- N3:  a. N301derive from internal beneficiary eligibility file; and  b. N302derive, as necessary, from internal beneficiary eligibility file as necessary; otherwise populate spaces.    2330A- N4:  Upon implementation of the 5010 Errata, the A/B MAC  (B) and DME MAC shared systems shall not attempt to gap -fill or systems -fill any elements (N401 N407) within this segment.  Also, if these elements are available but are incomplete, the shared systems shall not create the N4 segment tied to loop 2330A within the ASC X12 837 COB flat file.
(Medicare Claims Processing Manual)
a. N401derive from internal beneficiary eligibility file; and  b. N402, N403, N404, N407derive from internal beneficiary eligibility file if available and applicable; otherwise populate spaces.   14. The 2010BB loop denotes the payer name.  Per the HIPAA Implementation Guide, this loop should define the secondary payer when sending the claim to the second destination payer.  Thus, since the payer related to the COBA ID w ill be unknown by the shared systems, the shared system shall format the NM1, N3, and N4 segments as follows, with the BCRC completing any missing information:   2010BBNM1:   a. NM101populate PR;  b. NM102populate 2; c. NM103populate spaces; d. NM108populate PI; and  e. NM109populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).    2010BB-N3 & 2010BB- N4:  a. N301 & N302populate spaces; and  b. For N401, N402, N403, N404, N407, populate spaces.  15. The shared system s hall not  create the 2000C or the 2010CA loops within the ASC X12 837 new version professional COB flat file.  16. If the shared system notes the presence of other payers within 2320 SBR and 2330B loops that had made no financial determination on a claim prior to Medicare, as in the case of Medicare secondary payer (MSP) situations, the shared system shall not move those loops to the ASC X12 837 new version COB professional flat file.   17. The 2330B loop denotes other payers for the claim following Medicare.  There will always be one (1) 2330B that denotes Medicare as a payer, with the shared system completing all required information for NM101, NM102, NM103, NM108, NM109, as well as the N3 and N4 segments.
(Medicare Claims Processing Manual)
18. For additional 2330B loop iterations relating to COB, if the A/B MAC (B) or DME MAC receives multiple COBA IDs via the BOI reply trailer (29), payer information for additional COBA IDs will be unknown.  As with the 2010BB loop, the shared system shall format the NM1 segment as follows, with the  BCRC completing missing information:   2nd and additional iterations of 2330BNM1:   a. NM101populate PR;  b. NM102popula te 2;  c. NM103populate spaces; d. NM108populate PI; and  e. NM109populate the COBA ID (5 digit COBA ID as obtained from the BOI reply trailer 29).    2nd and additional iterations of 2330B-N3 & 2330B- N4:  a. N301 & N302populate spaces; and b. For N401, N402, N403, N404, N407, populate spaces.  19. The shared system shall always send at least one (1) complete iteration of 2320, 2330A, and 2330B on all ASC X12 837 COB flat files.  20. For 2300 REF (4081-Mandatory Crossover Indicator), the shared syst em shall take the action indicated below in accordance with the applicable scenario:   a. REF01, always map F5;   b. REF02, map Y if the COBA ID returned via the BOI reply trailer (29)=55000 through 55999 (Medigap claim- based crossover); and    c. REF02, map N if the COBA ID returned via the BOI reply trailer (29) =anything except for 55000 through 55999 (regular crossover).  Additional Mapping Requirements When Incoming Claim is Paper/Hard- Copy   **IMPORTANT:  The shared system shall create an outbound new version skinny claim, as derived from paper/hard copy claim input, in the same manner that it now does in creating the current in- use (prior to new version) claim, unless otherwise specified above or below.
(Medicare Claims Processing Manual)
1. The shared system shall always  map NDC codes keye d from hard -copy claims to the field that corresponds to 2410 LIN03 on the ASC X12 837 new version COB professional flat file.  In addition, the shared system shall auto-plug the appropriate qualifier that designated NDC within the field that corresponds to 2410 LIN02.    2. If the incoming paper claim contains an NPI in block 32 of the Form CMS-1500, the shared system shall continue to utilize this keyed value for purposes of deriving the information necessary to populate all required segments associated with 2310C (Service Facility Name).  The shared system shall continue to not create the 2310C loop if block 32 on the incoming paper claim is blank.  3. If the incoming claim is paper and does not contain information necessary to derive 2410 CTP5-1 (in association with Part B drugs), the shared system shall auto-plug the value F2.  III. Gap- Filling Requirements for ASC X12 837 New Version COB Files (Effective July 2012)  A. ASC X12  837 Institutional COB Claims  1. For all instances of the N403 segment, where created, FISS shall ensure that it creates a 5-byte base ZIP code and additional 4-byte component for the COB flat file when required.  2. FISS shall universally gap- fill or systems -fill required individual address elements, when not otherwise obtainable, for Subscriber-related loops as follows:  N401 (City Name) = Cityville;  N402 (State or Province Code) = MD; and  N403 (Postal Zone/ZIP Code) = 96941.  NOTE :   The  above is partic ularly  applic able in the creation of the indic ated segme nts within the 2010BA loop when the neede d data are individua lly not otherwise  unavailabl e.   3. FISS shall gap -fill the +4 ZIP code component with 9998 when the actual +4 ZIP code component is unavailable when creating the N403 in association with loops 2010AA (Billing Provider) and 2310E (Service Facility).  ( NOTE:   The full 9-byte ZIP code is required only for the N403 segment of the indicated loops.)
(Medicare Claims Processing Manual)
4. FISS shall never input 0000 as a gap- fill or system-fill +4 ZIP code in association with any of the N403 segments.  5a. If the shared system has valid city, state, and 5-byte ZIP code information available, it shall only gap- fill or system-fill the +4 ZIP code component, where required, with 9998 when creating outbound ASC X12 837 COB claim files.  5b. The shared system shall continue to send full ZIP code content (9-bytes) on outbound ASC X12 837 COB claim files, if available, for creation of situational N403 segments.   6. When the shared system determines that it has data within its internal provider file to populate 2010AA PER 04, it shall only move that information to the corresponding flat file field if the available data are complete.  If the available data are incomplete (i.e., fewer than 10 digits for telephone number), the shared system shall no t attempt to gap- fill the missing digits.  The shared system shall also not create that PER segment.   7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME MACs internal beneficiary eligibility record contains blank or incomplete line-1 street address information, FISS shall apply Xs to satisfy the minimum length requirements of the N301 segments.     8. If the incoming claim is paper Form CMS -1450 or DDE- entered and the dosage information necessary to populate 2410 CTP05-1 is not available, FISS shall always default to the value of F2.
(Medicare Claims Processing Manual)
9. If the incoming claim is paper or electronic, FISS shall map non- specific procedure code within the ASC X12 837 new version 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 Guide, 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&DLEntries=10&DLPa ge=1&DLSortDir=descending&DLFilter=NOC   10. FISS 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 new version COB flat file.  I n addition, if information needed to create the N4 segment is available but is incomplete, FISS shall not create the loop 2330B N4 segment.   11. FISS shall not attempt to gap -fill or systems -fill any of the composite SVD03 elements within loop 2430.  B. ASC X12  837 Professional COB Claims  1. For all instances of the N403 segment, where created, the A/B MAC ( B) and DME MAC shared systems shall ensure that it creates a 5 -byte base ZIP code and additional 4-byte component for the COB flat file when required.  2. The A/B MAC (B) and DME MAC shared systems shall universally gap- fill or system -fill required individual address elements, when not otherwise obtainable, for all Subsc riber-related loops as follows:  N401 (City Name) = Cityville;  N402 (State or Province Code) = MD; and  N403 (Postal Zone/ZIP Code) = 96941.  NOTE : The  above is partic ularly  applic able in the creation of the indic ated segme nts within the 2010BA loop when the neede d data are individua lly otherwise  not unavailabl e.
(Medicare Claims Processing Manual)
3. The A/B MAC (B) and DME MAC shared systems shall gap- fill the +4 ZIP code component with 9998 when the actual +4 ZIP code component is unavailable when creating the N403 in association with loops 2010AA (Billing Provider), 2310C (Service Facility claim level), and 2420C (Service Facilityservice line level).  (NOTE:   The full 9-byte ZIP code is required only for the N403 segment of the indicated loops.)  4. The A/B MAC (B) and DME MAC shared systems shall never input 0000 as a gap-fill or system- fill + 4 ZIP code in association with any of the N403 segments.  5a. If the A/B MAC (B) and DME MAC shared systems have valid city, state, and 5-byte ZIP code  information available, they shall only gap- fill or system- fill the +4 ZIP code component, where required, with 9998 when creating outbound ASC X12 837 COB claim files.  5b. The A/B MAC (B) and DME MAC shared system shall continue to send full ZIP code content (9-bytes) on outbound ASC X12 837 COB claim files, if available, for creation of situational N403segments   6. When the shared system determines that it has data within its internal provider file to populate 2010AA PER 04, it shall only move that information to the corresponding flat file field if the available data are complete.  If the available data are incomplete (i.e., fewer than 10 digits for telephone number), the shared system shall not attempt to gap- fill the equivalent field on the new version COB flat file.    7. With respect to 2010BA N301 and 2330A N301, when the A/B MAC (B) or DME MACs internal beneficiary eligibility record contains blank or incomplete line-1 street address information, the shared system shall apply Xs to satisfy the minimum length requirements of the N301 segments.  8a. In association with paper- submitted Part B ambu lance claims, the A/B MAC (B) shared system shall apply gap-filling to the N3 and N4 portions of loop 2310E and 2310F as follows for the segments indicated: