|
Each quarter (during the months of January, April, July, and October), and sometimes on an emergency basis or in a special release, changes related to enchancements and problems are placed into the Part B Medicare carrier system (MCS). Some of these changes may impact vendor system programming for Medicare. Information regarding changes will be posted on this section of the EDI Services Web site.
April 2008 Release Information - Updated 3-7-08
Posted March 7, 2008
Programming Information for the 835 NPI Stage 3, File Creation, and Check or EFT Distribution
The following changes are currently scheduled for implementation into the Medicare processing system with the April 2008 release.
Adjudication of claims will be based on your legacy identifier associated with your National Provider Identifier (NPI) as noted on the NPI to legacy crosswalk. The related 835s will be created by unique billing NPI and Provider Transaction Access Number (PTAN) (previously known as Provider Identification Number (PIN)) pairs. There will be a separate ST through SE (file) for each unique billing PTAN and NPI pair. Therefore, a single transmission could contain multiple files. Please refer to the examples at the end of this article, showing what the files would look like and the checks or Electronic Funds Transfers (EFTs) that would be created related to the examples.
A key difference between Stage 2 and Stage 3 is that NPIs will be returned in most remittance transactions as the primary Payee Identifier and the Taxpayer Identification Number (TIN) as the additional payee identifier rather than the current practice of reporting TIN and legacy number respectively, even though the inbound claim file may have included the legacy number and NPI on the claim. Please refer to applicable scenarios as outlined in the MLN Matters article MM5452 for impact of Stage 3 on remittances. This document breaks out the different scenarios related to adjudication when there is a one-to-one match of NPI to PTAN, when there are multiple NPIs crosswalked to a single Medicare legacy number, or a single NPI crosswalked to multiple Medicare legacy numbers.
835 Standard Remittance Advice and NPI Stage 3
- The 835 will no longer contain legacy PTANs, except in rare instances.
- The 1000B loop will be changed to report the billing NPI as the primary payee identifier in the N1 segment and the Tax ID will be reported as the secondary payee identifier in the REF segment. For the 1000B N1 segment, we will map data elements N101 and N102 as currently done. We will map "XX" to N103. The billing provider NPI from the claim will be mapped to N104. For the 1000B REF segment, we will map TJ to the REF01 and the billing provider's EIN or SSN (when no EIN is present) from the Medicare provider master file to REF02.
- The 2100 service provider name NM1 segment (NM101=82) will be changed to only report the first detail rendering NPI when different than the billing NPI. If the rendering provider NPI on the first detail of the claim is different than the billing provider NPI, we will map NM101 through NM109 for that rendering provider NPI. If the rendering provider NPI on the first detail of the claim is the same as the billing provider NPI, we will not create the 2100 NM1 segment.
- The 2110 Rendering Provider Information REF segment will only report when the 2nd detail rendering NPI is different than the billing NPI and different than the 1st detail rendering NPI. We will map qualifier HPI to REF01 and the detail rendering NPI to REF02. We will not create a 2110 REF if the NPI is the same as previously reported in the 2100 NM1.
- The PLB segment will continue to only be created when there is a provider level adjustment to the payment and will be changed to report the billing NPI in PLB01. The remaining PLB data elements will be mapped as currently done.
In those instances where a legacy PTAN will still be reported, the mapping will be as follows:
- The 1000B N101 & N102 will be mapped as currently done. Qualifier FI will be mapped to N103 and the billing provider's Tax ID (EIN or SSN) from the Medicare provider master file in N104.
- The 1000B REF will contain the 1C qualifier in REF01 and the billing PTAN in REF02.
- For the 2100 loop, NM1, if the 1st detail rendering NPI is not available, we will check for a rendering PTAN. If the rendering PTAN is different than the billing PTAN, we will map NM108 with qualifier UP and NM109 with the rendering provider's UPIN - if available. If not, we will map FI to NM108 and NM109 will contain the tax ID.
- For the 2110 REF, if the NPI is not available and the rendering PTAN is different than the billing PTAN and different than the 1st detail rendering PTAN, then we'll build the 2110 REF with 1C in REF01 and the rendering PTAN in REF02. If the PTANs are the same, we will not build the segment. 2110 REF will not be built with any provider identifier that previously occurred in the 2100 NM1.
- If there's a provider level adjustment to the payment, and no valid NPI, then we will map the billing PTAN. The remaining PLB data elements will be mapped as currently done.
Below are simple examples of the 835, depicting when multiple NPI/PTAN pairs are reported on an 835:
EXAMPLE # 1
| 1111111111 |
AC1234 |
| 2222222222 |
AC1234 |
| 3333333333 |
AC1234 |
The TJ qualifier means the next number is the tax ID. Therefore, 999999999 = Provider Tax ID #.
Three (3) claims are received, one (1) for each of the three (3) NPIs tied to the same PTAN. A separate ST/SE will be created for each NPI/PTAN pair. All claim/detail loops were left out for simplicity.
ST
BPR02 75.00
1000B N103 XX N104 1111111111
1000B REF01 TJ REF02 999999999
SE
ST
BPR02 55.00
1000B N103 XX N104 2222222222
1000B REF01 TJ REF02 999999999
SE
ST
BPR02 65.00
1000B N103 XX N104 3333333333
1000B REF01 TJ REF02 999999999
SE
Three (3) separate checks/EFTs would be created for each NPI and would match each BPR amount.
If only one (1) claim was submitted (for whichever NPI) - you would only have one remittance or 835, because that claim is adjudicated under the one NPI/PTAN combination, and you would have one (1) related check/EFT.
-------------------------------------------------------------------------------------------------------
EXAMPLE # 2
| 1111111111 |
AAAAAA |
| 1111111111 |
BBBBBB |
| 1111111111 |
CCCCCC |
The TJ qualifier means the next number is the tax ID. Therefore, 999999999 = Provider Tax ID #.
Three (3) claims are received for the one NPI tied to three (3) different PTANs. A separate ST/SE will be created for the NPI/PTAN pair. All claim/detail loops are left out for simplicity.
ST
BPR02 75.00
1000B N103 XX N104 1111111111
1000B REF01 TJ REF02 999999999
SE
ST
BPR02 25.00
1000B N103 XX N104 1111111111
1000B REF01 TJ REF02 999999999
SE
ST
BPR02 45.00
1000B N103 XX N104 1111111111
1000B REF01 TJ REF02 999999999
SE
Three (3) separate checks/EFTs would be created for NPI 1111111111 and would match each BPR amount.
If two (2) claims were submitted with the NPI and one processed with PTAN AAAAAA and the other processed with BBBBBB, then two (2) remits would be created with an ST/SE for NPI 1111111111, however, you will not see the individual PTANs in the file. Two (2) separate checks would be produced to match the remits.
Creation of the remittance is dependent upon the NPI/PTAN numbers the claim is adjudicated with. Each claim would only ever be adjudicated with one NPI/PTAN pair. When there are multiple claims processed under different NPI/PTAN combinations, you would see multiple remits though only the one NPI (each associated with the different PTANs / pairs - though the PTAN is not returned in the remittance). Therefore, it is important to be sure that you can associate the NPI submitted with the PTAN that it was enumerated with.
January 2008 Release Information
Posted October 29, 2007
835 COBOL Picture Changes
Currently, if SVC01-1 qualifier = N4 (National Drug Code Format), then SVC05 (Paid Units of Service - Quantity) or SVC07 (Original Units of Service - Quantity) are formatted as 9999999.99. If SVC01-1 = anything other than N4, then the SVC05 is formatted as 999.9 and SVC07 is formatted as 9999999.99.
Effective January 1, 2008, the ANSI 835 mapping will modify the format of the SVC05 and SVC07 so that no matter what qualifier is sent in the SVC01-1 [N4 - National Drug Code in 5-4-2 Format or HC - Health Care Procedural Coding System (HCPCS)], the SVC05 and SVC07 will be formatted as 9999999.99.
October 2007 Release Information - Updated 10-16-07
Posted October 16, 2007
Vendor Information for Chiropractic Billing
Claims have been received electronically that contain an invalid value in the 2300 and 2400 loops CR212 - Condition Response Indicator field in the Spinal Manipulation Service Information CR2 Segment. Data element CR212 indicates X-ray Available. When these claims are forwarded to the Coordination of Benefits Contractor (COBC), they are being rejected for invalid values.
The only acceptable values in the field are a "Y" or "N" for yes or no (X-ray is, or is not, available). Beginning in October, existing implementation guide pre-pass edits 0436 or 0764 will report on the provider's Batch Detail Listing (or "RAR04" electronic report), if the CR212 is submitted with anything other than a valid value and the claim will be rejected. CR212 is situational, but if used, must contain a valid value.
December 2006 Release Information
Posted November 9, 2006
Electronic Error Report: Reference Number – Patient Account Number - Field Fix
Due to the addition of the National Provider Identifier (NPI) to the EDI electronic report — the Batch Detail Control Report - H99RAR04 — the “Reference Number” field that holds the patient account number when there are errors at the claim level was inadvertently truncated to 11 characters. A special system release will fix this on December 8, 2006, and the “Reference Number” field will be 20 characters in length once again. The “Field Contents” field will be decreased from 22 to 13 characters in length to accommodate this change. A review of these reports shows that 13 characters is a sufficient length for “Field Contents.”
This example  shows that the “Reference Number” and “Field Contents” fields have been highlighted and filled with “Xs” to clearly display the size and placement of each of these fields.
October 2006 Release Information - Updated 11-3-06
Posted November 3, 2006
835 BPR02 COBOL Picture Change
The 835 BPR02 Total Actual Provider Payment Amount has been updated from a COBOL picture of S9(7)V99 to S9(8)V99 for translation from the CMS flat file. However, the Medicare allowance for this field does not exceed $999,999.00.
National Provider Identifier (NPI) in Remittance Transaction 835 – Stage 2
Beginning in Stage 2 of the NPI implementation, the 835 HIPAA version 4010A1 will be modified to report the NPI if it is received on a claim and validated in the Medicare processing system. Loop 2100 and 2110 will be modified to report the 10 digit numeric NPI and associated XX qualifier when submitted and accepted on inbound claims.
Currently, the billing provider Tax ID Number (TIN) is mapped to the 1000B loop N1 segment and the Medicare PTAN is mapped to the 1000B REF segment. The 2100 loop NM1 (service provider) segment is only created when the rendering provider PTAN on the claim’s first detail is different than the billing provider PTAN. When the provider numbers are the same, the 2100 NM1 is not created. When the 2100 NM1 is created the NM109 contains either the rendering provider UPIN or TIN. The 2100 REF is not created. The 2110 loop REF (rendering provider) segment is only created when the service line rendering provider PTAN is different than the billing provider PTAN. When the provider numbers are the same, the 2100 REF is not created. When the 2100 REF is created, the REF02 contains either the rendering or performing provider legacy PTAN.
New Requirements:
The 835 2100 loop NM1 segment will be modified when a rendering provider NPI is present on the claim. If a rendering provider NPI is present on the first detail of the claim record, the 2100 NM1 segment will contain the NPI even if the rendering and billing provider numbers are the same.
- Qualifier 82 will be mapped to NM101
- Qualifier 1 will be mapped to NM102
- Qualifier XX will be mapped to NM108
- The claim record rendering NPI will be mapped to the NM109
If there is not a rendering provider NPI present on the first detail of the claim, then we will build the 2100 NM1 segment only when the first detail rendering PTAN is different than the billing PTAN (map as currently done).
The 835 2110 loop (rendering provider) REF segment mapping will be changed when a rendering provider NPI is present on the detail service.
- We will create the 2110 REF segment (Rendering Provider Information) when the detail rendering provider NPI reported at the service level is different than the billing provider NPI.
- Qualifier HPI will be mapped to REF01 and the detail rendering NPI to REF02.
If there is not a detail rendering NPI on the service line, then we will create a 2110 REF segment (Rendering Provider Information) when the rendering provider PTAN reported at the service level is different than the billing provider PTAN. We will continue to map qualifier 1C in REF01 and the detail rendering PTAN in REF02 as currently done. When there is a detail rendering NPI on the service line a REF with the PTAN will not be created.
The above requirements will be repeated for every service line on the claim.
May 2006 Release Information
Posted April 4, 2005
ANSI Delimiters
The HIPAA-compliant EDI format is the American National Standards Institute (ANSI) 837 version 4010A1. The ANSI format must be “translated” and mapped to a flat file before it can be loaded into the Part B Medicare carrier system (MCS). The translation process relies on special characters called delimiters to separate and terminate the strings of data created by an 837 program (behind the scenes in practice management software). The character that is used as a delimiter in software cannot be used in the data content that is submitted in the claim, otherwise, it will cause problems during translation.
In the Upstate Medicare Division’s (UMD’s) Trading Partner Agreement, sometimes referred to as “the companion document,” we suggest the use of certain characters as delimiters. Use of specific characters as delimiters is defined in the ISA envelope/control segment. For example, and as noted in Appendix A of the 837 Implementation Guide, A.1.2.7, an asterisk (*) may be used as a data element separator, a colon (:) as a sub-element or composite data element separator, and a tilde (~) as a segment terminator. As noted (in the paragraph below Matrix A.3) “occurrences of delimiter characters in transmitted data within a data element can result in errors in translation programs.”
In early May, UMD will be upgrading its translation software. The upgrade will appropriately reject a claim file that has a delimiter defined in the ISA envelope and used inappropriately in the claim. We’ve been running files through our parallel test system and it has been noted that there were a considerable volume of rejections due to a colon being used in the free-form NTE narrative segment when it had been defined in the ISA as the composite data element separator.
Please verify which characters are used as delimiters (as noted in the ISA segment) and refrain from using these in claim data content submissions.
June 2005 Release Information
Posted June 3, 2005
The following EDI translator changes will be implemented into production June.
The American National Standards Institute (ANSI) translator that the Upstate Medicare Division (UMD) uses will create a TA1/997 response for every ISA, regardless of control number in the ISA13. In the 997 response, the translator will create one transaction set (ST-SE) for every functional group (GS-GE), regardless of the control number in GS06.
Customers have been instructed in carrier trading partner companion documents to use unique values in control number fields for easier tracking of transmissions. However, this does not always happen. In production today, the translator combines and generates only one 997/TA1 acknowledgment when the control number in ISA13 is the same for multiple 4010A1 interchanges transmitted by the same submitter on the same day. Also currently, the translator combines and generates only one transaction set per functional group when the control number in GS06 is the same for multiple functional groups. Although the translator does edit all functional groups received and reflects the actual number received in AK903, the AK2-AK5 data is combined into one transaction set (ST-SE) when it should be separated out per functional group, since they are considered individual files. The 837 Professional Implementation Guide states, 997 Functional Acknowledgment, “There is only one Functional Acknowledgement Transaction Set per acknowledged functional group."
When submitters receive only one 997 for multiple interchange (ISA) transmissions, they sometimes assume we only received one file, and they either call the EDI department or they resend the same file again.
Multiple 997s for multiple interchanges will continue to be included in one file per submitter daily.
October 2004 Release Information
Posted September 27, 2004
Standard Level Editing
Prior to sending claims into the Part B Medicare Processing System (MCS), there are several edit routines that the file must pass through. One level checks for X12 standard requirements. We have recently reviewed this editing, to ensure that X12 standard requirements are being met. We have added logic to existing criteria (as noted in the implementation guide) for the following data elements. These are required at the X12 standard level when the related segment is used. Editing logic will reject files if these mandatory data elements are missing when the related segment is used.
| 837 Version 4010/4010A1 |
|
X12 Element Attributes |
X12 Flat File |
| BHT01 |
Hierarchical
Structure Code |
ID |
4-4 |
R |
|
|
0019 |
19 |
4 |
| BHT02 |
Transaction Set
Purpose Code |
ID |
2-2 |
R |
|
|
00, 18 |
23 |
2 |
| HL01 |
Hierarchical ID
Number |
AN |
1-12 |
R |
2000A |
|
|
19 |
12 |
| HL03 |
Hierarchical Level
Code |
ID |
1-2 |
R |
2000A |
|
20 |
43 |
2 |
| PRV01 |
Provider Code |
ID |
1-3 |
R |
2000A |
|
BI, PT |
19 |
3 |
| PRV02 |
Reference
Identification
Qualifier |
ID |
2-3 |
R |
2000A |
|
ZZ |
22 |
3 |
| PRV03 |
Provider Taxonomy
Code |
AN |
1-30 |
R |
2000A |
|
|
25 |
30 |
| CUR02 |
Currency Code |
ID |
3-3 |
R |
2000A |
|
|
22 |
3 |
| HL01 |
Hierarchical ID
Number |
AN |
1-12 |
R |
2000B |
|
|
19 |
12 |
| HL03 |
Hierarchical Level
Code |
ID |
1-2 |
R |
2000B |
|
22 |
43 |
2 |
| HL01 |
Hierarchical ID
Number |
AN |
1-12 |
R |
2000C |
|
|
19 |
12 |
| HL03 |
Hierarchical Level
Code |
ID |
1-2 |
R |
2000C |
|
23 |
43 |
2 |
| CLM01 |
Patient Account
Number |
AN |
1-38 |
R |
2300 |
|
|
19 |
20 |
| PWK01 |
Attachment Report
Type Code |
ID |
2-2 |
R |
2300 |
|
77, AS,
B2, B3,
B4, CT,
DA,
DG,
DS, EB,
MT,
NN,
OB, OZ,
PN, PO,
PZ, RB,
RR, RT |
19 |
2 |
| CN101 |
Contract Type Code |
ID |
2-2 |
R |
2300 |
|
02, 03,
04, 05,
06, 09 |
19 |
2 |
| K301 |
Fixed Format
Information |
AN |
1-80 |
R |
2300 |
|
|
19 |
80 |
| NTE02 |
Claim Note Text |
AN |
1-80 |
R |
2300 |
|
|
22 |
80 |
| CR701 |
Discipline Type
Code |
ID |
2-2 |
R |
2305 |
|
AI, MS,
OT, PT,
SN, ST |
19 |
2 |
| PRV01 |
Provider Code |
ID |
1-3 |
R |
2310A |
|
RF |
19 |
3 |
| PRV02 |
Reference
Identification
Qualifier |
ID |
2-3 |
R |
2310A |
|
ZZ |
22 |
3 |
| PRV03 |
Provider Taxonomy
Code |
AN |
1-30 |
R |
2310A |
|
|
25 |
30 |
| PRV01 |
Provider Code |
ID |
1-3 |
R |
2310B |
|
PE |
19 |
3 |
| PRV02 |
Reference
Identification
Qualifier |
ID |
2-3 |
R |
2310B |
|
ZZ |
22 |
3 |
| PRV03 |
Provider Taxonomy
Code |
AN |
1-30 |
R |
2310B |
|
|
25 |
30 |
| SBR01 |
Payer
Responsibility
Sequence Number
Code |
ID |
1-1 |
R |
2320 |
|
P, S, T |
19 |
1 |
| CAS01 |
Claim Adjustment
Group Code |
ID |
1-2 |
R |
2320 |
|
CO,
CR,
OA, PI,
PR |
19 |
2 |
| CAS02 |
Adjustment Reason
Code |
ID |
1-5 |
R |
2320 |
|
|
21 |
5 |
| SV101-1 |
Product or Service
ID Qualifier |
ID |
2-2 |
R |
2400 |
|
HC, IV,
ZZ |
19 |
2 |
| SV101-2 |
Procedure Code |
AN |
1-48 |
R |
2400 |
|
|
21 |
11 |
| CN101 |
Contract Type
Code |
ID |
2-2 |
R |
2400 |
|
01, 02,
03, 04,
05, 06,
09 |
19 |
2 |
| K301 |
Fixed Format
Information |
AN |
1-80 |
R |
2400 |
|
|
19 |
80 |
| NTE02 |
Line Note Text |
AN |
1-80 |
R |
2400 |
|
|
22 |
80 |
| PS101 |
Purchased Service
Provider Identifier |
AN |
1-30 |
R |
2400 |
|
|
19 |
30 |
| PRV01 |
Provider Code |
ID |
1-3 |
R |
2420A |
|
PE |
19 |
3 |
| PRV02 |
Reference
Identification
Qualifier |
ID |
2-3 |
R |
2420A |
|
ZZ |
22 |
3 |
| PRV01 |
Provider Code |
ID |
1-3 |
R |
2420F |
|
RF |
19 |
3 |
| PRV02 |
Reference
Identification Code |
ID |
2-3 |
R |
2420F |
|
ZZ |
22 |
3 |
| SVD01 |
Other Payer
Primary Identifier |
AN |
2-80 |
R |
2430 |
|
|
19 |
80 |
| CAS01 |
Claim Adjustment
Group Code |
ID |
1-2 |
R |
2430 |
|
CO,
CR,
OA, PI,
PR |
19 |
2 |
| CAS02 |
Adjustment Reason
Code |
ID |
1-5 |
R |
2430 |
|
|
21 |
5 |
| FRM01 |
Question
Number/Letter |
AN |
1-20 |
R |
2440 |
|
|
19 |
20 |
| SE01 |
Transaction
Segment Count |
N0 |
1-10 |
R |
|
|
|
19 |
10 |
| SE02 |
Transaction Set
Control Number |
AN |
4-9 |
R |
|
|
|
29 |
9 |
July 2004 Release Information
Posted August 12, 2004
Care Plan Oversight/Home Health Agency (CPO/HHA) services: For these claims, when place of service is 12 (Home), submit the HHA number in the 2420C REF02 with a REF01 of LU and FA in the NM101 of that loop.
|
 |
