835 Transaction Set Listing

Usage
Repeats

ISA - INTERCHANGE CONTROL HEADER

X12 Name:
Interchange Control Header
X12 Purpose:
To start and identify an interchange of zero or more functional groups and interchange-related control segments
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. All positions within each of the data elements must be filled.
  2. For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
  3. The first element separator defines the element separator to be used through the entire interchange.
  4. The ISA segment terminator defines the segment terminator used throughout the entire interchange.
  5. Spaces in the example interchanges are represented by "." for clarity.
TR3 Example:
ISA✱00✱..........✱01✱SECRET....✱ZZ✱SUBMITTERS.ID..✱ZZ✱RECEIVERS.ID...✱030101✱1253✱^✱00501✱000000905✱1✱T✱:~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I01
Authorization Information Qualifier
M 1
ID
2
Code identifying the type of information in the Authorization Information
CODE
DEFINITION
00
No Authorization Information Present (No Meaningful Information in I02)
03
Additional Data Identification
Required
2
I02
Authorization Information
M 1
AN
10
Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (I01)
This element is fixed in length with identical minimum and maximum lengths. Spaces are inserted to meet the minimum length in an AN data element. With the associated code 00 in ISA01 or ISA03, an all space value indicates no information.
Required
3
I03
Security Information Qualifier
M 1
ID
2
Code identifying the type of information in the Security Information
CODE
DEFINITION
00
No Security Information Present (No Meaningful Information in I04)
01
Password
Required
4
I04
Security Information
M 1
AN
10
This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03)
This element is fixed in length with identical minimum and maximum lengths. Spaces are inserted to meet the minimum length in an AN data element. With the associated code 00 in ISA01 or ISA03, an all space value indicates no information.
Required
5
I05
Interchange ID Qualifier
M 1
ID
2
Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified
This ID qualifies the Sender in ISA06.
CODE
DEFINITION
01
Duns (Dun & Bradstreet)
14
Duns Plus Suffix
20
Health Industry Number (HIN)
27
Carrier Identification Number as assigned by Health Care Financing Administration (HCFA)
28
Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA)
29
Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA)
30
U.S. Federal Tax Identification Number
33
National Association of Insurance Commissioners Company Code (NAIC)
ZZ
Mutually Defined
Required
6
I06
Interchange Sender ID
M 1
AN
15
Identification code published by the sender for other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element
Required
7
I05
Interchange ID Qualifier
M 1
ID
2
Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified
This ID qualifies the Receiver in ISA08.
CODE
DEFINITION
01
Duns (Dun & Bradstreet)
14
Duns Plus Suffix
20
Health Industry Number (HIN)
27
Carrier Identification Number as assigned by Health Care Financing Administration (HCFA)
28
Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA)
29
Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA)
30
U.S. Federal Tax Identification Number
33
National Association of Insurance Commissioners Company Code (NAIC)
ZZ
Mutually Defined
Required
8
I07
Interchange Receiver ID
M 1
AN
15
Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them
Required
9
I08
Interchange Date
M 1
DT
6
Date of the interchange
The date format is YYMMDD.
Required
10
I09
Interchange Time
M 1
TM
4
Time of the interchange
The time format is HHMM.
Required
11
I65
Repetition Separator
M 1
Type is not applicable; the repetition separator is a delimiter and not a data element; this field provides the delimiter used to separate repeated occurrences of a simple data element or a composite data structure; this value must be different than the data element separator, component element separator, and the segment terminator
Required
12
I11
Interchange Control Version Number
M 1
ID
5
Code specifying the version number of the interchange control segments
CODE
DEFINITION
00501
Standards Approved for Publication by ASC X12 Procedures Review Board through October 2003
Required
13
I12
Interchange Control Number
M 1
N
9
A control number assigned by the interchange sender
  1. The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
  2. Must be a positive unsigned number and must be identical to the value in IEA02.
Required
14
I13
Acknowledgment Requested
M 1
ID
1
Code indicating sender's request for an interchange acknowledgment
See Section B.1.1.5.1 for interchange acknowledgment information.
CODE
DEFINITION
0
No Interchange Acknowledgment Requested
1
Interchange Acknowledgment Requested (TA1)
Required
15
I14
Interchange Usage Indicator
M 1
ID
1
Code indicating whether data enclosed by this interchange envelope is test, production or information
CODE
DEFINITION
P
Production Data
T
Test Data
Required
16
I15
Component Element Separator
M 1
Type is not applicable; the component element separator is a delimiter and not a data element; this field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator

GS*HP - FUNCTIONAL GROUP HEADER

X12 Name:
Functional Group Header
X12 Purpose:
To indicate the beginning of a functional group and to provide control information
X12 Comments:
A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
GS✱XX✱SENDER CODE✱RECEIVERCODE✱19991231✱0802✱1✱X✱005010X221A1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
479
Functional Identifier Code
M 1
ID
2
Code identifying a group of application related transaction sets
This is the 2-character Functional Identifier Code assigned to each transaction set by X12. The specific code for a transaction set defined by this implementation guide is presented in section 1.2, Version Information.
CODE
DEFINITION
HP
Health Care Claim Payment/Advice (835)
Required
2
142
Application Sender's Code
M 1
AN
2/15
Code identifying party sending transmission; codes agreed to by trading partners
Use this code to identify the unit sending the information.
Required
3
124
Application Receiver's Code
M 1
AN
2/15
Code identifying party receiving transmission; codes agreed to by trading partners
Use this code to identify the unit receiving the information.
Required
4
373
Date
M 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: GS04 is the group date.
Use this date for the functional group creation date.
Required
5
337
Time
M 1
TM
4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
SEMANTIC: GS05 is the group time.
Use this time for the creation time. The recommended format is HHMM.
Required
6
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02.
For implementations compliant with this guide, GS06 must be unique within a single transmission (that is, within a single ISA to IEA enveloping structure). The authors recommend that GS06 be unique within all transmissions over a period of time to be determined by the sender.
Required
7
455
Responsible Agency Code
M 1
ID
1/2
Code identifying the issuer of the standard; this code is used in conjunction with Data Element 480
CODE
DEFINITION
X
Accredited Standards Committee X12
Required
8
480
Version / Release / Industry Identifier Code
M 1
AN
1/12
Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed
INDUSTRY NAME: Version, Release, or Industry Identifier Code
This is the unique Version/Release/Industry Identifier Code assigned to an implementation by X12N. The specific code for a transaction set defined by this implementation guide is presented in section 1.2, Version Information.
CODE SOURCE 881:Version / Release / Industry Identifier Code
CODE
DEFINITION
005010X221A1
Health Care Claim Payment/Advice

ST*835 - TRANSACTION SET HEADER

X12 Name:
Transaction Set Header
X12 Purpose:
To indicate the start of a transaction set and to assign a control number
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
ST✱835✱1234~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code uniquely identifying a Transaction Set
SEMANTIC: The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
The only valid value within this transaction set for ST01 is 835.
CODE
DEFINITION
835
Health Care Claim Payment/Advice
Required
2
329
Transaction Set Control Number
M 1
AN
4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
The Transaction Set Control Numbers in ST02 and SE02 must be identical. This unique number also aids in error resolution research. Start with a number, for example 0001, and increment from there. This number must be unique within a specific group and interchange, but it can be repeated in other groups and interchanges.
Not Used
3
1705
Implementation Convention Reference
O 1
AN
1/35
CODE
DEFINITION
005010X221A1
Health Care Claim Payment/Advice

BPR - FINANCIAL INFORMATION

X12 Name:
Beginning Segment for Payment Order/Remittance Advice
X12 Purpose:
To indicate the beginning of a Payment Order/Remittance Advice Transaction Set and total payment amount, or to enable related transfer of funds and/or information from payer to payee to occur
X12 Syntax:
  1. P0607
    If either BPR06 or BPR07 is present, then the other is required.
  2. C0809
    If BPR08 is present, then BPR09 is required.
  3. P1213
    If either BPR12 or BPR13 is present, then the other is required.
  4. C1415
    If BPR14 is present, then BPR15 is required.
  5. P1819
    If either BPR18 or BPR19 is present, then the other is required.
  6. C2021
    If BPR20 is present, then BPR21 is required.
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use the BPR to address a single payment to a single payee. A payee may represent a single provider, a provider group, or multiple providers in a chain. The BPR contains mandatory information, even when it is not being used to move funds electronically.
TR3 Example:
BPR✱C✱150000✱C✱ACH✱CTX✱01✱999999992✱DA✱123456✱1512345678✱999999999✱01✱999988880✱DA✱98765✱20030901~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
305
Transaction Handling Code
M 1
ID
1/2
Code designating the action to be taken by all parties
CODE
DEFINITION
C
Payment Accompanies Remittance Advice
Use this code to instruct your third party processor to move both funds and remittance detail together through the banking system.
D
Make Payment Only
Use this code to instruct your third party processor to move only funds through the banking system and to ignore any remittance information.
H
Notification Only
Use this code when the actual provider payment (BPR02) is zero and the transaction is not being used for Prenotification of Future Transfers. This indicates remittance information without any associated payment.
I
Remittance Information Only
Use this code to indicate to the payee that the remittance detail is moving separately from the payment.
P
Prenotification of Future Transfers
This code is used only by the payer and the banking system to initially validate account numbers before beginning an EFT relationship. Contact your VAB for additional information.
U
Split Payment and Remittance
Use this code to instruct the third party processor to split the payment and remittance detail, and send each on a separate path.
X
Handling Party's Option to Split Payment and Remittance
Use this code to instruct the third party processor to move the payment and remittance detail, either together or separately, based upon end point requests or capabilities.
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: BPR02 specifies the payment amount.
INDUSTRY NAME: Total Actual Provider Payment Amount
  1. Use BPR02 for the total payment amount for this 835. The total payment amount for this 835 cannot exceed eleven characters, including decimals (99999999.99). Although the value can be zero, the 835 cannot be issued for less than zero dollars.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point).
Required
3
478
Credit/Debit Flag Code
M 1
ID
1
Code indicating whether amount is a credit or debit
INDUSTRY NAME: Credit or Debit Flag Code
CODE
DEFINITION
C
Credit
Use this code to indicate a credit to the provider's account and a debit to the payer's account, initiated by the payer. In the case of an EFT, no additional action is required of the provider. Also use this code when a check is issued for the payment.
D
Debit
Use this code to indicate a debit to the payer's account and a credit to the provider's account, initiated by the provider at the instruction of the payer. Extreme caution must be used when using Debit transactions. Contact your VAB for information about debit transactions. The rest of this segment and document assumes that a credit payment is being used.
Required
4
591
Payment Method Code
M 1
ID
3
Code identifying the method for the movement of payment instructions
CODE
DEFINITION
ACH
Automated Clearing House (ACH)
Use this code to move money electronically through the ACH, or to notify the provider that an ACH transfer was requested. When this code is used, see BPR05 through BPR15 for additional requirements.
BOP
Financial Institution Option
Use this code to indicate that the third party processor will choose the method of payment based upon end point requests or capabilities. When this code is used, see BPR05 through BPR15 for additional requirements.
CHK
Check
Use this code to indicate that a check has been issued for payment.
FWT
Federal Reserve Funds/Wire Transfer - Nonrepetitive
Use this code to indicate that the funds were sent through the wire system. When this code is used, see BPR05 through BPR15 for additional requirements.
NON
Non-Payment Data
Use this code when the Transaction Handling Code (BPR01) is H, indicating that this is information only and no dollars are to be moved.
Situational
5
812
Payment Format Code
O 1
ID
1/10
Code identifying the payment format to be used
SITUATIONAL RULE: Required when BPR04 is ACH. If not required by this implementation guide, do not send.
CODE
DEFINITION
CCP
Cash Concentration/Disbursement plus Addenda (CCD+) (ACH)
Use the CCD+ format to move money and up to 80 characters of data, enough to reassociate dollars and data when the dollars are sent through the ACH and the data is sent on a separate path. The addenda must contain a copy of the TRN segment.
CTX
Corporate Trade Exchange (CTX) (ACH)
Use the CTX format to move dollars and data through the ACH. The CTX format can contain up to 9,999 addenda records of 80 characters each. The CTX encapsulates the complete 835 and all envelope segments.
Situational
6
506
(DFI) ID Number Qualifier
O 1
ID
2
Code identifying the type of identification number of Depository Financial Institution (DFI)
SEMANTIC: When using this transaction set to initiate a payment, all or some of BPR06 through BPR16 may be required, depending on the conventions of the specific financial channel being used.
SEGMENT SYNTAX: P0607
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Depository Financial Institution (DFI) Identification Number Qualifier
BPR06 through BPR09 relate to the originating financial institution and the originator's account (payer).
CODE
DEFINITION
01
ABA Transit Routing Number Including Check Digits (9 digits)
The ABA transit routing number is a unique number identifying every bank in the United States.
CODE SOURCE 4: ABA Routing Number
04
Canadian Bank Branch and Institution Number
CODE SOURCE 91: Canadian Financial Institution Branch and Institution Number
Situational
7
507
(DFI) Identification Number
O 1
AN
3/12
Depository Financial Institution (DFI) identification number
SEGMENT SYNTAX: P0607
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Sender DFI Identifier
Use this number for the identifying number of the financial institution sending the transaction into the applicable network.
CODE SOURCE 60:(DFI) Identification Number
Situational
8
569
Account Number Qualifier
O 1
ID
1/3
Code indicating the type of account
SEMANTIC: BPR08 is a code identifying the type of bank account or other financial asset.
SEGMENT SYNTAX: C0809
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
Use this code to identify the type of account in BPR09.
CODE
DEFINITION
DA
Demand Deposit
Situational
9
508
Account Number
O 1
AN
1/35
Account number assigned
SEMANTIC: BPR09 is the account of the company originating the payment. This account may be debited or credited depending on the type of payment order.
SEGMENT SYNTAX: C0809
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Sender Bank Account Number
Use this number for the originator's account number at the financial institution.
Situational
10
509
Originating Company Identifier
O 1
AN
10
A unique identifier designating the company initiating the funds transfer instructions, business transaction or assigning tracking reference identification.
SEMANTIC: BPR10 shall be mutually established between the originating depository financial institution (ODFI) and the company originating the payment.
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Identifier
Situational
11
510
Originating Company Supplemental Code
O 1
AN
9
A code defined between the originating company and the originating depository financial institution (ODFI) that uniquely identifies the company initiating the transfer instructions
SITUATIONAL RULE: Required when BPR10 is present and the payee has a business need to receive further identification of the source of the payment (such as identification of the payer by division or region). If not required by this implementation guide, do not send.
Use this code to further identify the payer by division or region. The element must be left justified and space filled to meet the minimum element size requirements. If used, this code must be identical to TRN04, excluding trailing spaces.
Situational
12
506
(DFI) ID Number Qualifier
O 1
ID
2
Code identifying the type of identification number of Depository Financial Institution (DFI)
SEMANTIC: BPR12 and BPR13 relate to the receiving depository financial institution (RDFI).
SEGMENT SYNTAX: P1213
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Depository Financial Institution (DFI) Identification Number Qualifier
BPR12 through BPR15 relate to the receiving financial institution and the receiver's account.
CODE
DEFINITION
01
ABA Transit Routing Number Including Check Digits (9 digits)
The ABA transit routing number is a unique number identifying every bank in the United States.
CODE SOURCE 4: ABA Routing Number
04
Canadian Bank Branch and Institution Number
CODE SOURCE 91: Canadian Financial Institution Branch and Institution Number
Situational
13
507
(DFI) Identification Number
O 1
AN
3/12
Depository Financial Institution (DFI) identification number
SEGMENT SYNTAX: P1213
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Receiver or Provider Bank ID Number
Use this number for the identifying number of the financial institution receiving the transaction from the applicable network.
CODE SOURCE 60:(DFI) Identification Number
Situational
14
569
Account Number Qualifier
O 1
ID
1/3
Code indicating the type of account
SEMANTIC: BPR14 is a code identifying the type of bank account or other financial asset.
SEGMENT SYNTAX: C1415
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
Use this code to identify the type of account in BPR15.
CODE
DEFINITION
DA
Demand Deposit
SG
Savings
Situational
15
508
Account Number
O 1
AN
1/35
Account number assigned
SEMANTIC: BPR15 is the account number of the receiving company to be debited or credited with the payment order.
SEGMENT SYNTAX: C1415
SITUATIONAL RULE: Required when BPR04 is ACH, BOP or FWT. If not required by this implementation guide, do not send.
INDUSTRY NAME: Receiver or Provider Account Number
Use this number for the receiver's account number at the financial institution.
Required
16
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: BPR16 is the date the originating company intends for the transaction to be settled (i.e., Payment Effective Date).
INDUSTRY NAME: Check Issue or EFT Effective Date
Use this for the effective entry date. If BPR04 is ACH, this is the date that the money moves from the payer and is available to the payee. If BPR04 is CHK, this is the check issuance date. If BPR04 is FWT, this is the date that the payer anticipates the money to move. As long as the effective date is a business day, this is the settlement date. If BPR04 is `NON', enter the date of the 835.
Not Used
17
1048
Business Function Code
O 1
ID
1/3
Not Used
18
506
(DFI) ID Number Qualifier
O 1
ID
2
Not Used
19
507
(DFI) Identification Number
O 1
AN
3/12
Not Used
20
569
Account Number Qualifier
O 1
ID
1/3
Not Used
21
508
Account Number
O 1
AN
1/35

TRN*1 - REASSOCIATION TRACE NUMBER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
X12 Set Notes:
COMMENT: The TRN segment is used to uniquely identify a claim payment and advice.
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This segment's purpose is to uniquely identify this transaction set and to aid in reassociating payments and remittances that have been separated.
TR3 Example:
TRN✱1✱12345✱1512345678✱999999999~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
CODE
DEFINITION
1
Current Transaction Trace Numbers
Required
2
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
INDUSTRY NAME: Check or EFT Trace Number
  1. This number must be unique within the sender/receiver relationship. The number is assigned by the sender. If payment is made by check, this must be the check number. If payment is made by EFT, this must be the EFT reference number. If this is a non-payment 835, this must be a unique remittance advice identification number.
  2. See 1.10.2.3, Reassociation of Dollars and Data, for additional information.
Required
3
509
Originating Company Identifier
O 1
AN
10
A unique identifier designating the company initiating the funds transfer instructions, business transaction or assigning tracking reference identification.
SEMANTIC: TRN03 identifies an organization.
INDUSTRY NAME: Payer Identifier
This must be a 1 followed by the payer's EIN (or TIN).
Situational
4
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN04 identifies a further subdivision within the organization.
SITUATIONAL RULE: Required when information beyond the Originating Company Identifier in TRN03 is necessary for the payee to identify the source of the payment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Originating Company Supplemental Code
If both TRN04 and BPR11 are used, they must be identical, excluding trailing spaces. Since BPR11 has a min/max value of 9/9, whenever both are used, this element is restricted to a maximum size of 9.

CUR*PR - FOREIGN CURRENCY INFORMATION

X12 Name:
Currency
X12 Purpose:
To specify the currency (dollars, pounds, francs, etc.) used in a transaction
X12 Syntax:
  1. C0807
    If CUR08 is present, then CUR07 is required.
  2. C0907
    If CUR09 is present, then CUR07 is required.
  3. L101112
    If CUR10 is present, then at least one of CUR11 or CUR12 are required.
  4. C1110
    If CUR11 is present, then CUR10 is required.
  5. C1210
    If CUR12 is present, then CUR10 is required.
  6. L131415
    If CUR13 is present, then at least one of CUR14 or CUR15 are required.
  7. C1413
    If CUR14 is present, then CUR13 is required.
  8. C1513
    If CUR15 is present, then CUR13 is required.
  9. L161718
    If CUR16 is present, then at least one of CUR17 or CUR18 are required.
  10. C1716
    If CUR17 is present, then CUR16 is required.
  11. C1816
    If CUR18 is present, then CUR16 is required.
  12. L192021
    If CUR19 is present, then at least one of CUR20 or CUR21 are required.
  13. C2019
    If CUR20 is present, then CUR19 is required.
  14. C2119
    If CUR21 is present, then CUR19 is required.
X12 Set Notes:
COMMENT: The CUR segment does not initiate a foreign exchange transaction.
X12 Comments:
See Figures Appendix for examples detailing the use of the CUR segment.
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the payment is not being made in US dollars. If not required by this implementation guide, do not send.
TR3 Notes:
When the CUR segment is not present, the currency of payment is defined as US dollars.
TR3 Example:
CUR✱PR✱CAD~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
PR
Payer
Required
2
100
Currency Code
M 1
ID
3
Code (Standard ISO) for country in whose currency the charges are specified
This is the currency code for the payment currency.
CODE SOURCE 5:Countries, Currencies and Funds
Not Used
3
280
Exchange Rate
O 1
R
4/10
Not Used
4
98
Entity Identifier Code
O 1
ID
2/3
Not Used
5
100
Currency Code
O 1
ID
3
Not Used
6
669
Currency Market/Exchange Code
O 1
ID
3
Not Used
7
374
Date/Time Qualifier
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
337
Time
O 1
TM
4/8
Not Used
10
374
Date/Time Qualifier
O 1
ID
3
Not Used
11
373
Date
O 1
DT
8
Not Used
12
337
Time
O 1
TM
4/8
Not Used
13
374
Date/Time Qualifier
O 1
ID
3
Not Used
14
373
Date
O 1
DT
8
Not Used
15
337
Time
O 1
TM
4/8
Not Used
16
374
Date/Time Qualifier
O 1
ID
3
Not Used
17
373
Date
O 1
DT
8
Not Used
18
337
Time
O 1
TM
4/8
Not Used
19
374
Date/Time Qualifier
O 1
ID
3
Not Used
20
373
Date
O 1
DT
8
Not Used
21
337
Time
O 1
TM
4/8

REF*EV - RECEIVER IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the receiver of the transaction is other than the payee (e.g., a clearinghouse or billing service). If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
TR3 Notes:
This is the business identification information for the transaction receiver. This may be different than the EDI address or identifier of the receiver. This is the initial receiver of the transaction. This information must not be updated if the transaction is routed through multiple intermediaries, such as clearinghouses, before reaching the payee.
TR3 Example:
REF✱EV✱1235678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
EV
Receiver Identification Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Receiver Identifier
Receiver Identification
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*F2 - VERSION IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when necessary to report the version number of the adjudication system that generated the claim payments in order for the payer to resolve customer service questions from the payee. If not required by this implementation guide, do not send.
TR3 Notes:
Update this reference number whenever a change in the version or release number affects the 835. (This is not the ANSI ASCX12 version number as reported in the GS segment.)
TR3 Example:
REF✱F2✱FS3.21~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
F2
Version Code - Local
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Version Identification Code
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

DTM*405 - PRODUCTION DATE

X12 Name:
Date/Time Reference
X12 Purpose:
To specify pertinent dates and times
X12 Syntax:
  1. R020305
    At least one of DTM02, DTM03 or DTM05 is required.
  2. C0403
    If DTM04 is present, then DTM03 is required.
  3. P0506
    If either DTM05 or DTM06 is present, then the other is required.
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the cut off date of the adjudication system remittance run is different from the date of the 835 as identified in the related GS04 element. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
If your adjudication cycle completed on Thursday and your 835 is produced on Saturday, you are required to populate this segment with Thursday's date.
TR3 Example:
DTM✱405✱20020317~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
405
Production
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Production Date
Report the end date for the adjudication production cycle for claims included in this 835.
Not Used
3
337
Time
O 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
O 1
ID
2/3
Not Used
6
1251
Date Time Period
O 1
AN
1/35

N1*PR - PAYER IDENTIFICATION

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
X12 Set Notes:
COMMENT: The N1 loop allows for name/address information for the payer and payee which would be utilized to address remittance(s) for delivery.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Use this N1 loop to provide the name/address information for the payer.
  2. The payer's secondary identifying reference number is provided in N104, if necessary.
TR3 Example:
N1✱PR✱INSURANCE COMPANY OF TIMBUCKTU✱XV✱8888888888~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
PR
Payer
Required
2
93
Name
O 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payer Name
Situational
3
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304
SITUATIONAL RULE: Required when reporting Health Plan Identifier (HPID) or Other Entity Identifier (OEID). If not required by this implementation guide, do not send.Prior to the mandated implementation date for Health Plan Identifier, willing trading partners may agree to:1. Follow a dual use approach in which the HPID or OEID and the Payer Identification Number are both sent.OR2. Follow an early implementation approach in which the HPID or OEID is sent in N104.
CODE
DEFINITION
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID
Situational
4
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when reporting Health Plan Identifier (HPID) or Other Entity Identifier (OEID). If not required by this implementation guide, do not send.Prior to the mandated implementation date for Health Plan Identifier, willing trading partners may agree to:1. Follow a dual use approach in which the HPID or OEID and the Payer Identification Number are both sent.OR2. Follow an early implementation approach in which the HPID or OEID is sent in N104.
INDUSTRY NAME: Payer Identifier
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3

N3 - PAYER ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N3✱100 MAIN STREET~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
166
Address Information
M 1
AN
1/55
Address information
INDUSTRY NAME: Payer Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when a second address line exists. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Address Line

N4 - PAYER CITY, STATE, ZIP CODE

X12 Name:
Geographic Location
X12 Purpose:
To specify the geographic place of the named party
X12 Syntax:
  1. E0207
    Only one of N402 or N407 may be present.
  2. C0605
    If N406 is present, then N405 is required.
  3. C0704
    If N407 is present, then N404 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N4✱KANSAS CITY✱MO✱64108~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
19
City Name
O 1
AN
2/30
Free-form text for city name
COMMENT: A combination of either N401 through N404, or N405 and N406 may be adequate to specify a location.
INDUSTRY NAME: Payer City Name
Situational
2
156
State or Province Code
O 1
ID
2
Code (Standard State/Province) as defined by appropriate government agency
COMMENT: N402 is required only if city name (N401) is in the U.S. or Canada.
SEGMENT SYNTAX: E0207
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer State Code
CODE SOURCE 22:States and Provinces
Situational
3
116
Postal Code
O 1
ID
3/15
Code defining international postal zone code excluding punctuation and blanks (zip code for United States)
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada, or when a postal code exists for the country in N404. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Postal Zone or ZIP Code
  • CODE SOURCE 51:ZIP Code
  • CODE SOURCE 932:Universal Postal Codes
Situational
4
26
Country Code
O 1
ID
2/3
Code identifying the country
SEGMENT SYNTAX: C0704
SITUATIONAL RULE: Required when the address is outside the United States of America. If not required by this implementation guide, do not send.
Use the alpha-2 country codes from Part 1 of ISO 3166.
CODE SOURCE 5:Countries, Currencies and Funds
Not Used
5
309
Location Qualifier
O 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Situational
7
1715
Country Subdivision Code
O 1
ID
1/3
Code identifying the country subdivision
SEGMENT SYNTAX: E0207, C0704
SITUATIONAL RULE: Required when the address is not in the United States of America, including its territories, or Canada, and the country in N404 has administrative subdivisions such as but not limited to states, provinces, cantons, etc. If not required by this implementation guide, do not send.
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5:Countries, Currencies and Funds

REF - ADDITIONAL PAYER IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
4
Situational Rule:
Required when additional payer identification numbers beyond those in the TRN and Payer N1 segments are needed. If not required by this implementation guide, may be sent at sender's discretion, but cannot be required by the receiver.
TR3 Notes:
The ID available in the TRN and N1 segments must be used before using the REF segment.
TR3 Example:
REF✱2U✱98765~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
2U
Payer Identification Number
For Medicare carriers or intermediaries, use this qualifier for the Medicare carrier or intermediary ID number. For Blue Cross and Blue Shield Plans, use this qualifier for the Blue Cross Blue Shield association plan code.
EO
Submitter Identification Number
This is required when the original transaction sender is not the payer or is identified by an identifier other than those already provided. This is not updated by third parties between the payer and the payee. An example of a use for this qualifier is when identifying a clearinghouse that created the 835 when the health plan sent a proprietary format to the clearinghouse.
HI
Health Industry Number (HIN)
CODE SOURCE 121: Health Industry Number
NF
National Association of Insurance Commissioners (NAIC) Code
This is the preferred value when identifying the payer.
CODE SOURCE 245: National Association of Insurance Commissioners (NAIC) Code
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Additional Payer Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

PER*CX - PAYER BUSINESS CONTACT INFORMATION

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when there is a business contact area that would apply to this remittance and all the claims. If not required by this implementation guide, do not send.
TR3 Notes:
When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number always includes the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (800) 555-1212 would be represented as 8005551212). The extension number, when applicable, is identified in the next element pair (Communications Number Qualifier and Communication Number) immediately after the telephone number.
TR3 Example:
PER✱CX✱JOHN WAYNE✱TE✱8005551212~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
CX
Payers Claim Office
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when it is necessary to identify an individual or other contact point to discuss information related to this transaction. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Name
Use this data element when the name of the individual to contact is not already defined or is different than the name within the prior name segment (e.g. N1 or NM1).
Situational
3
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when a contact communication number is to be transmitted. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Situational
4
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when a contact communication number is to be transmitted. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Communication Number
Situational
5
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when a second communication contact number is needed. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
When used, the value following this code is the extension for the preceding communications contact number.
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when a second communication contact number is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Communication Number
Situational
7
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Situational
8
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Communication Number
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

PER*BL - PAYER TECHNICAL CONTACT INFORMATION

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
>1
TR3 Notes:
Required to report technical contact information for this remittance advice.
TR3 Example:
PER✱BL✱JOHN WAYNE✱TE✱8005551212✱EX✱123~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
BL
Technical Department
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when it is necessary to identify an individual or other contact point to discuss technical information related to this transaction. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Technical Contact Name
Use this data element when the name of the individual to contact is not already defined or is different than the name within the prior name segment (e.g. N1 or NM1).
Situational
3
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when a contact communication number is to be transmitted. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
TE
Telephone
Recommended
UR
Uniform Resource Locator (URL)
Use only when there is no central telephone number for the payer entity.
Situational
4
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when a contact communication number is to be transmitted. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Communication Number
Situational
5
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when a second communication contact number is needed. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
When used, the value following this code is theextension for the preceding communicationscontact number.
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Situational
6
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Technical Contact Communication Number
Situational
7
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when a second communication contact number is needed. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
When used, the value following this code is theextension for the preceding communicationscontact number.
FX
Facsimile
UR
Uniform Resource Locator (URL)
Situational
8
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Contact Communication Number
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

PER*IC - PAYER WEB SITE

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when any 2110 loop Healthcare Policy REF Segment is used. If not required by this implementation guide, do not send.
TR3 Notes:
This is a direct link to the policy location of the un-secure website.
TR3 Example:
PER✱IC✱✱UR✱www.anyhealthplan.com/policies.html~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
IC
Information Contact
Not Used
2
93
Name
O 1
AN
1/60
Required
3
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
UR
Uniform Resource Locator (URL)
Required
4
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
This is the payer's WEB site URL where providers can find policy and other related information.
Not Used
5
365
Communication Number Qualifier
O 1
ID
2
Not Used
6
364
Communication Number
O 1
AN
1/256
Not Used
7
365
Communication Number Qualifier
O 1
ID
2
Not Used
8
364
Communication Number
O 1
AN
1/256
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

N1*PE - PAYEE IDENTIFICATION

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
X12 Set Notes:
COMMENT: The N1 loop allows for name/address information for the payer and payee which would be utilized to address remittance(s) for delivery.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this N1 loop to provide the name/address information of the payee. The identifying reference number is provided in N104.
TR3 Example:
N1✱PE✱MID-STATE MENTAL HOSPITAL✱XX✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
PE
Payee
Required
2
93
Name
O 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payee Name
Required
3
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
Required if provider is not mandated by NPI. For individual providers as payees, use this qualifier to represent the Social Security Number.
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID). This only applies in cases of post payment recovery. See section 1.10.2.16 (Post Payment Recovery) for further information.
CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID
XX
Centers for Medicare and Medicaid Services National Provider Identifier
This is REQUIRED when the National Provider Identifier is mandated for use and the payee is a covered health care provider under the mandate.
CODE SOURCE 537: Centers for Medicare and Medicaid Services National Provider Identifier
Required
4
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Payee Identification Code
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3

N3 - PAYEE ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the sender needs to communicate the payee address to a transaction receiver, e.g., a VAN or a clearinghouse. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Example:
N3✱SUITE 200✱1000 MAIN STREET~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
166
Address Information
M 1
AN
1/55
Address information
INDUSTRY NAME: Payee Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when a second address line exists. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payee Address Line

N4 - PAYEE CITY, STATE, ZIP CODE

X12 Name:
Geographic Location
X12 Purpose:
To specify the geographic place of the named party
X12 Syntax:
  1. E0207
    Only one of N402 or N407 may be present.
  2. C0605
    If N406 is present, then N405 is required.
  3. C0704
    If N407 is present, then N404 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the sender needs to communicate the payee address to a transaction receiver, e.g., a VAN or a clearinghouse. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Example:
N4✱KANSAS CITY✱MO✱64108~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
19
City Name
O 1
AN
2/30
Free-form text for city name
COMMENT: A combination of either N401 through N404, or N405 and N406 may be adequate to specify a location.
INDUSTRY NAME: Payee City Name
Situational
2
156
State or Province Code
O 1
ID
2
Code (Standard State/Province) as defined by appropriate government agency
COMMENT: N402 is required only if city name (N401) is in the U.S. or Canada.
SEGMENT SYNTAX: E0207
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payee State Code
CODE SOURCE 22:States and Provinces
Situational
3
116
Postal Code
O 1
ID
3/15
Code defining international postal zone code excluding punctuation and blanks (zip code for United States)
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada, or when a postal code exists for the country in N404. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payee Postal Zone or ZIP Code
  • CODE SOURCE 51:ZIP Code
  • CODE SOURCE 932:Universal Postal Codes
Situational
4
26
Country Code
O 1
ID
2/3
Code identifying the country
SEGMENT SYNTAX: C0704
SITUATIONAL RULE: Required when the address is outside the United States of America. If not required by this implementation guide, do not send.
Use the alpha-2 country codes from Part 1 of ISO 3166.
CODE SOURCE 5:Countries, Currencies and Funds
Not Used
5
309
Location Qualifier
O 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Situational
7
1715
Country Subdivision Code
O 1
ID
1/3
Code identifying the country subdivision
SEGMENT SYNTAX: E0207, C0704
SITUATIONAL RULE: Required when the address is not in the United States of America, including its territories, or Canada, and the country in N404 has administrative subdivisions such as but not limited to states, provinces, cantons, etc. If not required by this implementation guide, do not send.
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5:Countries, Currencies and Funds

REF - PAYEE ADDITIONAL IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
>1
Situational Rule:
Required when identification of the payee is dependent upon an identification number beyond that supplied in the N1 segment. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Example:
REF✱PQ✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
D3
National Council for Prescription Drug Programs Pharmacy Number
CODE SOURCE 307: National Council for Prescription Drug Programs Pharmacy Number
PQ
Payee Identification
TJ
Federal Taxpayer's Identification Number
This information must be in the N1 segment unless the National Provider ID or the Health Plan Identifier (HPID) or Other Entity Identifier (OEID) was used in N104. For individual providers as payees, use this number to represent the Social Security Number. TJ also represents the Employer Identification Number (EIN). According to the IRS, TIN and EIN can be used interchangeably.
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Additional Payee Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

RDM - REMITTANCE DELIVERY METHOD

X12 Name:
Remittance Delivery Method
X12 Purpose:
To identify remittance delivery when remittance is separate from payment
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when BPR01 = U or X; and the remittance is to be sent separately from the payment. The payer is responsible to provide the bank with the instructions on how to deliver the remittance information, if not required by this implementation guide, do not send.
TR3 Notes:
Payer should coordinate this process with their Originating Depository Financial Institution (ODFI).
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
756
Report Transmission Code
M 1
ID
1/2
Code defining timing, transmission method or format by which reports are to be sent
CODE
DEFINITION
BM
By Mail
When used, RDM02 must be used.

When BM is used, the remittance information will be mailed to the payee at the address identified in this 1000B loop.
EM
E-Mail
Use with encrypted e-mail.
FT
File Transfer
Use with FTP communications.
OL
On-Line
Use with secured hosted or other electronic delivery.
Situational
2
93
Name
O 1
AN
1/60
Free-form name
COMMENT: RDM02 is used to contain the name of a third party processor if needed, who would be the first recipient of the remittance.
SITUATIONAL RULE: Required when RDM01 = BM. If not required by this implementation guide, do not send.
When BM is used, the remittance information will be mailed to the attention of this person at the payee's address identified in this 1000B loop.
Situational
3
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
COMMENT: RDM03 contains the operative communication number for the delivery method specified in RDM01 (i.e. fax phone number and mail address).
SITUATIONAL RULE: Required when RDM01 equals EM, FT, or OL. If not required by this implementation guide, do not send.
Contains URL web address or e-mail address.
Not Used
4
C040
Reference Identifier
O 1
Not Used
5
C040
Reference Identifier
O 1

LX - HEADER NUMBER

X12 Name:
Transaction Set Line Number
X12 Purpose:
To reference a line number in a transaction set
X12 Set Notes:
NOTE: The LX segment is used to provide a looping structure and logical grouping of claim payment information.
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when claim/service information is being provided in the transaction. If not required by this implementation guide, do not send.
TR3 Notes:
  1. The purpose of LX01 is to provide an identification of a particular grouping of claims for sorting purposes.
  2. In the event that claim/service information must be sorted, the LX segment must precede each series of claim level and service level segments. This number is intended to be unique within each transaction.
TR3 Example:
  1. LX✱1~
  2. LX✱110210~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
554
Assigned Number
M 1
N
1/6
Number assigned for differentiation within a transaction set

TS3 - PROVIDER SUMMARY INFORMATION

X12 Name:
Transaction Statistics
X12 Purpose:
To supply provider-level control information
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for Medicare Part A or when payers and payees outside the Medicare Part A community need to identify provider subsidiaries whose remittance information is contained in the 835 transactions transmitted to a single provider entity [i.e., the corporate office of a hospital chain]. If not required by this implementation guide, do not send.
TR3 Notes:
  1. TS301 identifies the subsidiary provider.
  2. The remaining mandatory elements (TS302 through TS305) must be valid with appropriate data, as defined by the TS3 segment.
  3. Only Medicare Part A uses data elements TS313, TS315, TS317, TS318 and TS320 through TS324. Each monetary amount element is for that provider for this facility type code for loop 2000.
TR3 Example:
TS3✱123456✱11✱20021031✱10✱130957.66~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TS301 is the provider number.
INDUSTRY NAME: Provider Identifier
This is the provider number.
Required
2
1331
Facility Code Value
M 1
AN
1/2
Code identifying where services were, or may be, performed; the first and second positions of the Uniform Bill Type Code for Institutional Services or the Place of Service Codes for Professional or Dental Services.
INDUSTRY NAME: Facility Type Code
When reporting a TS3 segment for professional claims and the claims are not all for the same place of service, report a place of service of 11 (Office) as the default value. When reporting a TS3 segment for pharmaceutical claims and the claims are not all for the same place of service, report a place of service of 99 (Other unlisted facility) as the default value.
Required
3
373
Date
M 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: TS303 is the last day of the provider's fiscal year.
INDUSTRY NAME: Fiscal Period Date
Use this date for the last day of the provider's fiscal year. If the end of the provider's fiscal year is not known, use December 31st of the current year.
Required
4
380
Quantity
M 1
R
1/15
Numeric value of quantity
SEMANTIC: TS304 is the total number of claims.
INDUSTRY NAME: Total Claim Count
This is the total number of claims.
Required
5
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: TS305 is the total of reported charges.
INDUSTRY NAME: Total Claim Charge Amount
  1. This is the total reported charges for all claims.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all 782 elements.
Not Used
6
782
Monetary Amount
O 1
R
1/18
Not Used
7
782
Monetary Amount
O 1
R
1/18
Not Used
8
782
Monetary Amount
O 1
R
1/18
Not Used
9
782
Monetary Amount
O 1
R
1/18
Not Used
10
782
Monetary Amount
O 1
R
1/18
Not Used
11
782
Monetary Amount
O 1
R
1/18
Not Used
12
782
Monetary Amount
O 1
R
1/18
Situational
13
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS313 is the total Medicare Secondary Payer (MSP) primary payer amount.
SITUATIONAL RULE: Required when the Total MSP Payer Amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total MSP Payer Amount
See TR3 note 3.
Not Used
14
782
Monetary Amount
O 1
R
1/18
Situational
15
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS315 is the summary of non-lab charges.
SITUATIONAL RULE: Required when the Total Non-Lab charge amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Non-Lab Charge Amount
See TR3 note 3.
Not Used
16
782
Monetary Amount
O 1
R
1/18
Situational
17
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS317 is the Health Care Financing Administration Common Procedural Coding System (HCPCS) reported charges.
SITUATIONAL RULE: Required when the Total HCPCS Reported Charge Amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total HCPCS Reported Charge Amount
See TR3 note 3.
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS318 is the total Health Care Financing Administration Common Procedural Coding System (HCPCS) payable amount.
SITUATIONAL RULE: Required when the total HCPCS payable amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total HCPCS Payable Amount
See TR3 note 3.
Not Used
19
782
Monetary Amount
O 1
R
1/18
Situational
20
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS320 is the total professional component amount.
SITUATIONAL RULE: Required when the total professional component amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Professional Component Amount
  1. The professional component amount must also be reported in the CAS segment with a Claim Adjustment Reason Code value of 89.
  2. See TR3 note 3.
Situational
21
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS321 is the total Medicare Secondary Payer (MSP) patient liability met.
SITUATIONAL RULE: Required when the total MSP patient liability met is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total MSP Patient Liability Met Amount
See TR3 note 3.
Situational
22
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS322 is the total patient reimbursement.
SITUATIONAL RULE: Required when the total patient reimbursement is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Patient Reimbursement Amount
See TR3 note 3.
Situational
23
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS323 is the total periodic interim payment (PIP) number of claims.
SITUATIONAL RULE: Required when the Total PIP Claim Count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total PIP Claim Count
See TR3 note 3.
Situational
24
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS324 is total periodic interim payment (PIP) adjustment.
SITUATIONAL RULE: Required when the total PIP adjustment amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total PIP Adjustment Amount
See TR3 note 3.

TS2 - PROVIDER SUPPLEMENTAL SUMMARY INFORMATION

X12 Name:
Transaction Supplemental Statistics
X12 Purpose:
To provide supplemental summary control information by provider fiscal year and bill type
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for Medicare Part A. If not required by this implementation guide, do not send.
TR3 Notes:
  1. This segment provides summary information specific to an iteration of the LX loop (Table 2).
  2. Each element represents the total value for the provider/bill type combination in this loop 2000 iteration.
TR3 Example:
TS2✱59786✱55375.77~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Situational
1
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS201 is the total diagnosis related group (DRG) amount.
SITUATIONAL RULE: Required when the value of the Total DRG amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total DRG Amount
  1. This includes: operating federal-specific amount, operating hospital-specific amount, operating Indirect Medical Education amount, and operating Disproportionate Share Hospital amount. It does not include any operating outlier amount.
  2. See TR3 note 2.
Situational
2
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS202 is the total federal specific amount.
SITUATIONAL RULE: Required when total federal specific amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Federal Specific Amount
See TR3 note 2.
Situational
3
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS203 is the total hospital specific amount.
SITUATIONAL RULE: Required when total hospital specific amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Hospital Specific Amount
See TR3 note 2.
Situational
4
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS204 is the total disproportionate share amount.
SITUATIONAL RULE: Required when total disproportionate share amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Disproportionate Share Amount
See TR3 note 2.
Situational
5
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS205 is the total capital amount.
SITUATIONAL RULE: Required when total capital amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Capital Amount
  1. This includes: capital federal-specfic amount, hospital federal-specfic amount, hold harmless amount, Indirect Medical Education amount, Disproportionate Share Hospital amount, and the exception amount. It does not include any capital outlier amount.
  2. See TR3 note 2.
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS206 is the total indirect medical education amount.
SITUATIONAL RULE: Required when total indirect medical education amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Indirect Medical Education Amount
See TR3 note 2.
Situational
7
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS207 is the total number of outlier days.
SITUATIONAL RULE: Required when total outlier day count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Outlier Day Count
See TR3 note 2.
Situational
8
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS208 is the total day outlier amount.
SITUATIONAL RULE: Required when the value of the total day outlier amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Day Outlier Amount
See TR3 note 2.
Situational
9
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS209 is the total cost outlier amount.
SITUATIONAL RULE: Required when the value of the total cost outlier amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Cost Outlier Amount
See TR3 note 2.
Situational
10
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS210 is the diagnosis related group (DRG) average length of stay.
SITUATIONAL RULE: Required when the value of the average DRG length of stay is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Average DRG Length of Stay
See TR3 note 2.
Situational
11
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS211 is the total number of discharges.
SITUATIONAL RULE: Required when the value of the total discharge count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Discharge Count
  1. This is the discharge count produced by PPS PRICER SOFTWARE.
  2. See TR3 note 2.
Situational
12
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS212 is the total number of cost report days.
SITUATIONAL RULE: Required when the value of the total cost report day count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Cost Report Day Count
See TR3 note 2.
Situational
13
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS213 is the total number of covered days.
SITUATIONAL RULE: Required when the value of the total covered day count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Covered Day Count
See TR3 note 2.
Situational
14
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS214 is total number of non-covered days.
SITUATIONAL RULE: Required when the value of the total noncovered day count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Noncovered Day Count
See TR3 note 2.
Situational
15
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS215 is the total Medicare Secondary Payer (MSP) pass- through amount calculated for a non-Medicare payer.
SITUATIONAL RULE: Required when the value of the total MSP Pass-through amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total MSP Pass-Through Amount
See TR3 note 2.
Situational
16
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: TS216 is the average diagnosis-related group (DRG) weight.
SITUATIONAL RULE: Required when the value of the average DRG Weight is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Average DRG weight
See TR3 note 2.
Situational
17
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS217 is the total prospective payment system (PPS) capital, federal-specific portion, diagnosis-related group (DRG) amount.
SITUATIONAL RULE: Required when the value of the total PPS capital FSP (Federal-specific Portion) DRG amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total PPS Capital FSP DRG Amount
See TR3 note 2.
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS218 is the total prospective payment system (PPS) capital, hospital-specific portion, diagnosis-related group (DRG) amount.
SITUATIONAL RULE: Required when the value of the total PPS Capital HSP (Hospital-specific Portion) DRG Amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total PPS Capital HSP DRG Amount
See TR3 note 2.
Situational
19
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS219 is the total prospective payment system (PPS) disproportionate share, hospital diagnosis-related group (DRG) amount.
SITUATIONAL RULE: Required when the value of the Total PPS Capital DSH (Disproportionate Share, Hospital) DRG amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total PPS DSH DRG Amount
See TR3 note 2.

CLP - CLAIM PAYMENT INFORMATION

X12 Name:
Claim Level Data
X12 Purpose:
To supply information common to all services of a claim
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
For CLP segment occurrence limitations, see section 1.3.2, Other Usage Limitations.
TR3 Example:
CLP✱7722337✱1✱211366.97✱138018.4✱✱12✱119932404007801~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1028
Claim Submitter's Identifier
M 1
AN
1/38
Identifier used to track a claim from creation by the health care provider through payment
INDUSTRY NAME: Patient Control Number
Use this number for the patient control number assigned by the provider. If the patient control number is not present on the incoming claim, enter a single zero. The value in CLP01 must be identical to any value received as a Claim Submitter's Identifier on the original claim (CLM01 of the ANSI ASC X12 837, if applicable). This data element is the primary key for posting the remittance information into the provider's database. In the case of pharmacy claims, this is the prescription reference number (field 402-02 in the NCPDP 5.1 format).
Required
2
1029
Claim Status Code
M 1
ID
1/2
Code identifying the status of an entire claim as assigned by the payor, claim review organization or repricing organization
To determine the full claim status reference Claim adjustment reason codes in the CAS segment in conjunction with this claim status code.
CODE
DEFINITION
1
Processed as Primary
Use this code if the claim was adjudicated by the current payer as primary regardless of whether any part of the claim was paid.
2
Processed as Secondary
Use this code if the claim was adjudicated by the current payer as secondary regardless of whether any part of the claim was paid.
3
Processed as Tertiary
Use this code if the claim was adjudicated by the current payer as tertiary (or subsequent) regardless of whether any part of the claim was paid.
4
Denied
Usage of this code would apply if the Patient/Subscriber is not recognized, and the claim was not forwarded to another payer.
19
Processed as Primary, Forwarded to Additional Payer(s)
When this code is used, the Crossover Carrier Name NM1 segment is required.
20
Processed as Secondary, Forwarded to Additional Payer(s)
When this code is used, the Crossover Carrier Name NM1 segment is required.
21
Processed as Tertiary, Forwarded to Additional Payer(s)
When this code is used, the Crossover Carrier Name NM1 segment is required.
22
Reversal of Previous Payment
See section 1.10.2.8 for usage information.
23
Not Our Claim, Forwarded to Additional Payer(s)
Usage of this code would apply if the patient/subscriber is not recognized, the claim was not adjudicated by the payer, but other payers are known and the claim has been forwarded to another payer. When this code is used, the Crossover Carrier Name NM1 segment is required.
25
Predetermination Pricing Only - No Payment
Required
3
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: CLP03 is the amount of submitted charges this claim.
INDUSTRY NAME: Total Claim Charge Amount
  1. See 1.10.2.1, Balancing, in this implementation guide for additional information.
  2. Use this monetary amount for the submitted charges for this claim. The amount can be positive, zero or negative. An example of a situation with a negative charge is a reversal claim. See section 1.10.2.8 for additional information.
  3. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Required
4
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: CLP04 is the amount paid this claim.
INDUSTRY NAME: Claim Payment Amount
  1. See 1.10.2.1, Balancing, in this implementation guide for additional information. See section 1.10.2.9 for information about interest considerations.
  2. Use this monetary amount for the amount paid for this claim. It can be positive, zero or negative, but the value in BPR02 may not be negative.
Situational
5
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CLP05 is the patient responsibility amount.
SITUATIONAL RULE: Required when the patient's responsibility is greater than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Responsibility Amount
  1. Amounts in CLP05 must have supporting adjustments reflected in CAS segments at the 2100 (CLP) or 2110 (SVC) loop level with a Claim Adjustment Group (CAS01) code of PR (Patient Responsibility).
  2. Use this monetary amount for the payer's statement of the patient responsibility amount for this claim, which can include such items as deductible, non-covered services, co-pay and co-insurance. This is not used for reversals. See section 1.10.2.8, Reversals and Corrections, for additional information.
Required
6
1032
Claim Filing Indicator Code
O 1
ID
1/2
Code identifying type of claim
  1. For many providers to electronically post the 835 remittance data to their patient accounting systems without human intervention, a unique, provider-specific insurance plan code is needed. This code allows the provider to separately identify and manage the different product lines or contractual arrangements between the payer and the provider. Because most payers maintain the same Originating Company Identifier in the TRN03 or BPR10 for all product lines or contractual relationships, the CLP06 is used by the provider as a table pointer in combination with the TRN03 or BPR10 to identify the unique, provider-specific insurance plan code needed to post the payment without human intervention. The value should mirror the value received in the original claim (2-005 SBR09 of the 837), if applicable, or provide the value as assigned or edited by the payer. For example the BL from the SBR09 in the 837 would be returned as 12, 13, 15, in the 835 when more details are known. The 837 SBR09 code CI (Commercial Insurance) is generic, if through adjudication the specific type of plan is obtained a more specific code must be returned in the 835.
  2. The 837 and 835 transaction code lists for this element are not identical by design. There are some business differences between the two transactions. When a code from the 837 is not available in the 835 another valid code from the 835 must be assigned by the payer.
CODE
DEFINITION
12
Preferred Provider Organization (PPO)
This code is also used for Blue Cross/Blue Shield participating provider arrangements.
13
Point of Service (POS)
14
Exclusive Provider Organization (EPO)
15
Indemnity Insurance
This code is also used for Blue Cross/Blue Shield non-participating provider arrangements.
16
Health Maintenance Organization (HMO) Medicare Risk
17
Dental Maintenance Organization
AM
Automobile Medical
CH
Champus
DS
Disability
HM
Health Maintenance Organization
LM
Liability Medical
MA
Medicare Part A
MB
Medicare Part B
MC
Medicaid
OF
Other Federal Program
Use this code for the Black Lung Program.
TV
Title V
VA
Veterans Affairs Plan
WC
Workers' Compensation Health Claim
ZZ
Mutually Defined
Required
7
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: CLP07 is the payer's internal control number.
INDUSTRY NAME: Payer Claim Control Number
Use this number for the payer's internal control number. This number must apply to the entire claim.
Situational
8
1331
Facility Code Value
O 1
AN
1/2
Code identifying where services were, or may be, performed; the first and second positions of the Uniform Bill Type Code for Institutional Services or the Place of Service Codes for Professional or Dental Services.
SITUATIONAL RULE: Required when the information was received on the original claim. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Facility Type Code
  1. Since professional or dental claims can have different place of service codes for services within a single claim, default to the place of service of the first service line when the service lines are not all for the same place of service.
  2. This number was received in CLM05-1 of the 837 claim.
Situational
9
1325
Claim Frequency Type Code
O 1
ID
1
Code specifying the frequency of the claim; this is the third position of the Uniform Billing Claim Form Bill Type
SITUATIONAL RULE: Required when the information was received on the original claim. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Claim Frequency Code
This number was received in CLM05-3 of the 837 Claim.
CODE SOURCE 235:Claim Frequency Type Code
Not Used
10
1352
Patient Status Code
O 1
ID
1/2
Situational
11
1354
Diagnosis Related Group (DRG) Code
O 1
ID
1/4
Code indicating a patient's diagnosis group based on a patient's illness, diseases, and medical problems
SITUATIONAL RULE: Required for institutional claims when the claim was adjudicated using a DRG. If not required by this implementation guide, do not send.
CODE SOURCE 229:Diagnosis Related Group Number (DRG)
Situational
12
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CLP12 is the diagnosis-related group (DRG) weight.
SITUATIONAL RULE: Required for institutional claims when the claim was adjudicated using a DRG. If not required by this implementation guide, do not send.
INDUSTRY NAME: Diagnosis Related Group (DRG) Weight
This is the adjudicated DRG Weight.
Situational
13
954
Percentage as Decimal
O 1
R
1/10
Percentage expressed as a decimal (e.g., 0.0 through 1.0 represents 0% through 100%)
SEMANTIC: CLP13 is the discharge fraction.
SITUATIONAL RULE: Required when a discharge fraction was applied in the adjudication process. If not required by this implementation guide, do not send.
INDUSTRY NAME: Discharge Fraction
This is the adjudicated discharge fraction.
Not Used
14
1073
Yes/No Condition or Response Code
O 1
ID
1

CAS - CLAIM ADJUSTMENT

X12 Name:
Claims Adjustment
X12 Purpose:
To supply adjustment reason codes and amounts as needed for an entire claim or for a particular service within the claim being paid
X12 Syntax:
  1. L050607
    If CAS05 is present, then at least one of CAS06 or CAS07 are required.
  2. C0605
    If CAS06 is present, then CAS05 is required.
  3. C0705
    If CAS07 is present, then CAS05 is required.
  4. L080910
    If CAS08 is present, then at least one of CAS09 or CAS10 are required.
  5. C0908
    If CAS09 is present, then CAS08 is required.
  6. C1008
    If CAS10 is present, then CAS08 is required.
  7. L111213
    If CAS11 is present, then at least one of CAS12 or CAS13 are required.
  8. C1211
    If CAS12 is present, then CAS11 is required.
  9. C1311
    If CAS13 is present, then CAS11 is required.
  10. L141516
    If CAS14 is present, then at least one of CAS15 or CAS16 are required.
  11. C1514
    If CAS15 is present, then CAS14 is required.
  12. C1614
    If CAS16 is present, then CAS14 is required.
  13. L171819
    If CAS17 is present, then at least one of CAS18 or CAS19 are required.
  14. C1817
    If CAS18 is present, then CAS17 is required.
  15. C1917
    If CAS19 is present, then CAS17 is required.
X12 Set Notes:
NOTE: The CAS segment is used to reflect changes to amounts within Table 2.
X12 Comments:
Adjustment information is intended to help the provider balance the remittance information. Adjustment amounts should fully explain the difference between submitted charges and the amount paid.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
99
Situational Rule:
Required when dollar amounts and/or quantities are being adjusted at the claim level. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Payers must use this CAS segment to report claim level adjustments that cause the amount paid to differ from the amount originally charged. See 1.10.2.1, Balancing, and 1.10.2.4, Claim Adjustment and Service Adjustment Segment Theory, for additional information.
  2. See the SVC TR3 Note #1 for details about per diem adjustments.
  3. A single CAS segment contains six repetitions of the "adjustment trio" composed of adjustment reason code, adjustment amount, and adjustment quantity. These six adjustment trios are used to report up to six adjustments related to a specific Claim Adjustment Group Code (CAS01). The six iterations (trios) of the Adjustment Reason Code related to the Specific Adjustment Group Code must be exhausted before repeating a second iteration of the CAS segment using the same Adjustment Group Code. The first adjustment must be the first non-zero adjustment and is reported in the first adjustment trio (CAS02-CAS04). If there is a second non-zero adjustment, it is reported in the second adjustment trio (CAS05-CAS07), and so on through the sixth adjustment trio (CAS17-CAS19).
TR3 Example:
CAS✱PR✱1✱793✱✱3✱25~CAS✱CO✱131✱250~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1033
Claim Adjustment Group Code
M 1
ID
1/2
Code identifying the general category of payment adjustment
Evaluate the usage of group codes in CAS01 based on the following order for their applicability to a set of one or more adjustments: PR, CO, PI, OA. See 1.10.2.4, Claim Adjustment and Service Adjustment Segment Theory, for additional information. (Note: This does not mean that the adjustments must be reported in this order.)
CODE
DEFINITION
CO
Contractual Obligations
Use this code when a joint payer/payee contractual agreement or a regulatory requirement resulted in an adjustment.
OA
Other adjustments
Avoid using the Other Adjustment Group Code (OA) except for business situations described in sections 1.10.2.6, 1.10.2.7 and 1.10.2.13.
PI
Payor Initiated Reductions
Use this code when, in the opinion of the payer, the adjustment is not the responsibility of the patient, but there is no supporting contract between the provider and the payer (i.e., medical review or professional review organization adjustments).
PR
Patient Responsibility
Required
2
1034
Claim Adjustment Reason Code
M 1
ID
1/5
Code identifying the detailed reason the adjustment was made
INDUSTRY NAME: Adjustment Reason Code
Required to report a non-zero adjustment applied at the claim level for the claim adjustment group code reported in CAS01.
CODE SOURCE 139:Claim Adjustment Reason Code
Required
3
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: CAS03 is the amount of adjustment.
INDUSTRY NAME: Adjustment Amount
  1. Use this monetary amount for the adjustment amount. A negative amount increases the payment, and a positive amount decreases the payment contained in CLP04.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Situational
4
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS04 is the units of service being adjusted.
SITUATIONAL RULE: Required when the CAS02 adjustment reason code is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
  1. See section 1.10.2.4.1 for additional information.
  2. A positive value decreases the covered days, and a negative number increases the covered days.
Situational
5
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L050607, C0605, C0705
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS06 is the amount of the adjustment.
SEGMENT SYNTAX: L050607, C0605
SITUATIONAL RULE: Required when CAS05 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
7
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS07 is the units of service being adjusted.
SEGMENT SYNTAX: L050607, C0705
SITUATIONAL RULE: Required when CAS05 is present and is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
8
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L080910, C0908, C1008
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
9
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS09 is the amount of the adjustment.
SEGMENT SYNTAX: L080910, C0908
SITUATIONAL RULE: Required when CAS08 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
10
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS10 is the units of service being adjusted.
SEGMENT SYNTAX: L080910, C1008
SITUATIONAL RULE: Required when CAS08 is present and is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
11
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L111213, C1211, C1311
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
12
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS12 is the amount of the adjustment.
SEGMENT SYNTAX: L111213, C1211
SITUATIONAL RULE: Required when CAS11 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
13
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS13 is the units of service being adjusted.
SEGMENT SYNTAX: L111213, C1311
SITUATIONAL RULE: Required when CAS11 is present and is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
14
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L141516, C1514, C1614
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
15
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS15 is the amount of the adjustment.
SEGMENT SYNTAX: L141516, C1514
SITUATIONAL RULE: Required when CAS14 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
16
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS16 is the units of service being adjusted.
SEGMENT SYNTAX: L141516, C1614
SITUATIONAL RULE: Required when CAS14 is present and is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
17
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L171819, C1817, C1917
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS18 is the amount of the adjustment.
SEGMENT SYNTAX: L171819, C1817
SITUATIONAL RULE: Required when CAS17 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
19
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS19 is the units of service being adjusted.
SEGMENT SYNTAX: L171819, C1917
SITUATIONAL RULE: Required when CAS17 is present and is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.

NM1*QC - PATIENT NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Provide the patient's identification number in NM109.
  2. This segment must provide the information from the original claim. For example, when the claim is submitted as an ASC X12 837 transaction, this is the 2010CA loop NM1 Patient Name Segment unless not present on the original claim, then it is the 2010BA loop NM1 Subscriber name segment.
  3. The Corrected Patient/Insured Name NM1 segment identifies the adjudicated Insured Name and ID information if different than what was submitted on the claim.
TR3 Example:
NM1✱QC✱1✱SHEPHARD✱SAM✱O✱✱✱HN✱666666666A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
QC
Patient
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
Situational
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required for all claims that are not Retail Pharmacy claims or for Retail Pharmacy claims when the information is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the patient has a first name and it is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the patient has a middle name or initial and it is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Middle Name or Initial
If this data element is used and contains only one character, it is assumed to represent the middle initial.
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when this information is necessary for identification of the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Name Suffix
An example of this is when a Junior and Senior are covered under the same subscriber.
Situational
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the patient identifier (NM109) is known or was reported on the healthcare claim. If not required by this implementation guide, do not send.
CODE
DEFINITION
34
Social Security Number
HN
Health Insurance Claim (HIC) Number
II
Standard Unique Health Identifier for each Individual in the United States
Use this code if mandated in a final Federal Rule.
MI
Member Identification Number
MR
Medicaid Recipient Identification Number
Situational
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the patient identifier is known or was reported on the health care claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*IL - INSURED NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the original claim reported the insured or subscriber (for example 837 2010BA loop Subscriber Name NM1 Segment) that is different from the patient. If not required by this implementation guide, do not send.
TR3 Notes:
  1. In the case of Medicare and Medicaid, the insured patient is always the subscriber and this segment is not used.
  2. This segment contains the same information as reported on the claim (for example 837 2010BA loop Subscriber Name NM1 Segment when the patient was reported in the 2010CA loop Patient Name NM1 Segment).
TR3 Example:
NM1✱IL✱1✱SHEPARD✱JESSICA✱✱✱✱MI✱999887777A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
IL
Insured or Subscriber
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when the last name (NM102=1) or organization name (NM102=2) is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the subscriber is a person (NM102=1) and the first name is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the subscriber is a person (NM102=1) and the middle name or initial is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber Middle Name or Initial
If this data element is used and contains only one character, it is assumed to represent the middle initial.
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when the subscriber is a person (NM102=1), the information is known and this information is necessary for identification of the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber Name Suffix
For example, use when necessary to differentiate between a Junior and Senior under the same contract.
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
Not Used when NM102=1.
II
Standard Unique Health Identifier for each Individual in the United States
Use this code if mandated in a final Federal Rule.
MI
Member Identification Number
The code MI is intended to identify that the subscriber's identification number as assigned by the payer will be conveyed in NM109. Payers use different terminology to convey the same number, therefore, the 835 workgroup recommends using MI (Member Identification number) to convey the same categories of numbers as represented in the 837 IGs for the inbound claims.
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Subscriber Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*74 - CORRECTED PATIENT/INSURED NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when needed to provide corrected information about the patient or insured. If not required by this implementation guide, do not send.
TR3 Notes:
Since the patient is always the insured for Medicare and Medicaid, this segment always provides corrected patient information for Medicare and Medicaid. For other carriers, this will always be the corrected insured information.
TR3 Example:
NM1✱74✱1✱SHEPARD✱SAMUEL✱O✱✱✱C✱666666666A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
74
Corrected Insured
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when the insured is a person (NM102=1) AND the submitted vs adjudicated data is different. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Insured Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the insured is a person (NM102=1) AND the submitted vs adjudicated data is different. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Insured First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the insured is a person (NM102=1) AND the submitted vs adjudicated data is different AND the information is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Insured Middle Name
If this data element is used and contains only one character, it is assumed to represent the middle initial.
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when the insured is a person (NM102=1) and corrected information for the insured is available and this information is necessary for identification of the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Insured Name Suffix
Situational
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when a value is reported in NM109. If not required by this implementation guide, do not send.
CODE
DEFINITION
C
Insured's Changed Unique Identification Number
Situational
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the adjudicated patient/insured identification number is different than the identification submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Insured Identification Indicator
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*82 - SERVICE PROVIDER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the rendering provider is different from the payee. If not required by this implementation guide, do not send.
TR3 Notes:
  1. This segment provides information about the rendering provider. An identification number is provided in NM109.
  2. This information is provided to facilitate identification of the claim within a payee's system. Other providers (e.g., Referring provider, supervising provider) related to the claim but not directly related to the payment are not supported and are not necessary for claim identification.
TR3 Example:
NM1✱82✱2✱✱✱✱✱✱XX✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
82
Rendering Provider
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when a unique name is necessary for identification of the provider identified in NM109. If not required, may be provided at sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Rendering Provider Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the Servicing Provider is a person (NM102=1), NM103 is used AND the information is known from systems of the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Rendering Provider First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the Servicing Provider is a person (NM102=1), NM103 is used AND the information is known from systems of the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Rendering Provider Middle Name or Initial
If this data element is used and contains only one character, it represents the middle initial.
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when the Servicing Provider is a person (NM102=1), NM103 is used and this information is necessary for identification of the individual, for instance when a Junior and Senior are both providers in the same practice. If not required by this implementation guide, do not send.
INDUSTRY NAME: Rendering Provider Name Suffix
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
BD
Blue Cross Provider Number
BS
Blue Shield Provider Number
FI
Federal Taxpayer's Identification Number
This is the preferred ID until the National Provider ID is mandated and applicable.
For individual providers as payees, use this qualifier to represent the Social Security Number.
MC
Medicaid Provider Number
PC
Provider Commercial Number
SL
State License Number
UP
Unique Physician Identification Number (UPIN)
XX
Centers for Medicare and Medicaid Services National Provider Identifier
Required value if the National Provider ID is mandated for use and the provider is a covered health care provider under the mandate. Otherwise, one of the other listed codes may be used.
CODE SOURCE 537: Centers for Medicare and Medicaid Services National Provider Identifier
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Rendering Provider Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*TT - CROSSOVER CARRIER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the claim is transferred to another carrier or coverage (CLP02 equals 19, 20, 21 or 23). If not required by this implementation guide, do not send.
TR3 Notes:
This segment provides information about the crossover carrier. Provide any reference numbers in NM109. The crossover carrier is defined as any payer to which the claim is transferred for further payment after being finalized by the current payer.
TR3 Example:
NM1✱TT✱2✱ACME INSURANCE✱✱✱✱✱XV✱123456789~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
TT
Transfer To
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Coordination of Benefits Carrier Name
Name of the crossover carrier associated with this claim.
Not Used
4
1036
Name First
O 1
AN
1/35
Not Used
5
1037
Name Middle
O 1
AN
1/25
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Not Used
7
1039
Name Suffix
O 1
AN
1/10
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
AD
Blue Cross Blue Shield Association Plan Code
FI
Federal Taxpayer's Identification Number
NI
National Association of Insurance Commissioners (NAIC) Identification
This is the preferred ID unless XV is used.
PI
Payor Identification
PP
Pharmacy Processor Number
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID). Otherwise, one of the other listed codes may be used.
CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Coordination of Benefits Carrier Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*PR - CORRECTED PRIORITY PAYER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when current payer believes that another payer has priority for making a payment and the claim is not being automatically transferred to that payer. If not required by this implementation guide, do not send.
TR3 Notes:
Provide any reference numbers in NM109. Use of this segment identifies the priority payer. Do not use this segment when the Crossover Carrier NM1 segment is used.
TR3 Example:
NM1✱PR✱2✱ACME INSURANCE✱✱✱✱✱XV✱123456789~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
PR
Payer
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Corrected Priority Payer Name
Not Used
4
1036
Name First
O 1
AN
1/35
Not Used
5
1037
Name Middle
O 1
AN
1/25
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Not Used
7
1039
Name Suffix
O 1
AN
1/10
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
AD
Blue Cross Blue Shield Association Plan Code
FI
Federal Taxpayer's Identification Number
NI
National Association of Insurance Commissioners (NAIC) Identification
This is the preferred ID unless XV is used.
PI
Payor Identification
PP
Pharmacy Processor Number
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID). Otherwise, one of the other listed codes may be used.
CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Corrected Priority Payer Identification Number
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

NM1*GB - OTHER SUBSCRIBER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a corrected priority payer has been identified in another NM1 segment AND the name or ID of the other subscriber is known. If not required by this implementation guide, do not send.
TR3 Notes:
This is the name and ID number of the other subscriber when a corrected priority payer has been identified. When used, either the name or ID must be supplied.
TR3 Example:
NM1✱GB✱Smith✱Jane~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
GB
Other Insured
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when known or when NM109 is not present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Other Subscriber Last Name
At least one of NM103 or NM109 must be present.
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the Other Subscriber is a person (NM102=1), NM103 is present and the first name is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Other Subscriber First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the Other Subscriber is a person (NM102=1) and the middle name or initial is known. If not required by this implementation guide, do not send.
INDUSTRY NAME: Other Subscriber Middle Name or Initial
When only one character is present this is assumed to be the middle initial.
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when the Other Subscriber is a person (NM102=1), the information is known and this information is necessary for identification of the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Other Subscriber Name Suffix
Situational
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is known. If not required by this implementation guide, do not send.
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
Not Used when NM102=1.
II
Standard Unique Health Identifier for each Individual in the United States
Use this code if mandated in a final Federal Rule.
MI
Member Identification Number
Use this code when supplying the number used for identification of the subscriber in NM109.
Situational
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when known or when NM103 is not present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Other Subscriber Identifier
At least one of NM103 or NM109 must be present.
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

MIA - INPATIENT ADJUDICATION INFORMATION

X12 Name:
Medicare Inpatient Adjudication
X12 Purpose:
To provide claim-level data related to the adjudication of Medicare inpatient claims
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for all inpatient claims when there is a need to report Remittance Advice Remark Codes at the claim level or, the claim is paid by Medicare or Medicaid under the Prospective Payment System (PPS). If not required by this implementation guide, do not send.
TR3 Notes:
  1. When used outside of the Medicare and Medicaid community only MIA01, 05, 20, 21, 22 and 23 may be used.
  2. Either MIA or MOA may appear, but not both.
  3. This segment must not be used for covered days or lifetime reserve days. For covered or lifetime reserve days, use the Supplemental Claim Information Quantities Segment in the Claim Payment Loop.
  4. All situational quantities and/or monetary amounts in this segment are required when the value of the item is different than zero.
TR3 Example:
MIA✱0✱✱✱138018.4~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
380
Quantity
M 1
R
1/15
Numeric value of quantity
SEMANTIC: MIA01 is the covered days.
INDUSTRY NAME: Covered Days or Visits Count
Implementers utilizing the MIA segment always transmit the number zero. See the QTY segment at the claim level for covered days or visits count.
Situational
2
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA02 is the Prospective Payment System (PPS) Operating Outlier amount.
SITUATIONAL RULE: Required when an additional payment is made for excessive cost incurred by the provider when the payer is Medicare or Medicaid and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS Operating Outlier Amount
  1. See TR3 note 4.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Situational
3
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: MIA03 is the lifetime psychiatric days.
SITUATIONAL RULE: Required for psychiatric claims when the payer is Medicare or Medicaid and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Lifetime Psychiatric Days Count
Situational
4
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA04 is the Diagnosis Related Group (DRG) amount.
SITUATIONAL RULE: Required for claims paid under a Diagnostic Related Group when the payer is Medicare or Medicaid and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim DRG Amount
Situational
5
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MIA05 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when a claim level Claim Payment Remark Code applies to this claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA06 is the disproportionate share amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Disproportionate Share Amount
Situational
7
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA07 is the Medicare Secondary Payer (MSP) pass-through amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim MSP Pass-through Amount
Situational
8
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA08 is the total Prospective Payment System (PPS) capital amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim PPS Capital Amount
Situational
9
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA09 is the Prospective Payment System (PPS) capital, federal specific portion, Diagnosis Related Group (DRG) amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital FSP DRG Amount
Situational
10
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA10 is the Prospective Payment System (PPS) capital, hospital specific portion, Diagnosis Related Group (DRG), amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital HSP DRG Amount
Situational
11
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA11 is the Prospective Payment System (PPS) capital, disproportionate share, hospital Diagnosis Related Group (DRG) amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital DSH DRG Amount
Situational
12
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA12 is the old capital amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Old Capital Amount
Situational
13
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA13 is the Prospective Payment System (PPS) capital indirect medical education claim amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital IME amount
Situational
14
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA14 is hospital specific Diagnosis Related Group (DRG) Amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Operating Hospital Specific DRG Amount
Situational
15
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: MIA15 is the cost report days.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Cost Report Day Count
Situational
16
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA16 is the federal specific Diagnosis Related Group (DRG) amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Operating Federal Specific DRG Amount
Situational
17
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA17 is the Prospective Payment System (PPS) Capital Outlier amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim PPS Capital Outlier Amount
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA18 is the indirect teaching amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Indirect Teaching Amount
Situational
19
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA19 is the professional component amount billed but not payable.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Nonpayable Professional Component Amount
Situational
20
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MIA20 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
21
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MIA21 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
22
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MIA22 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
23
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MIA23 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
24
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA24 is the capital exception amount.
SITUATIONAL RULE: Required when Medicare or Medicaid is the payer and the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital Exception Amount

MOA - OUTPATIENT ADJUDICATION INFORMATION

X12 Name:
Medicare Outpatient Adjudication
X12 Purpose:
To convey claim-level data related to the adjudication of Medicare claims not related to an inpatient setting
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for outpatient/professional claims where there is a need to report a Remittance Advice Remark Code at the claim level or when the payer is Medicare or Medicaid and MOA01, 02, 08 or 09 are non-zero. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Either MIA or MOA may appear, but not both.
  2. All situational quantities and/or monetary amounts in this segment are required when the value of the item is different than zero.
TR3 Example:
MOA✱✱✱MA01~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Situational
1
954
Percentage as Decimal
O 1
R
1/10
Percentage expressed as a decimal (e.g., 0.0 through 1.0 represents 0% through 100%)
SEMANTIC: MOA01 is the reimbursement rate.
SITUATIONAL RULE: Required when the outpatient institutional claim reimbursement rate is not zero for a Medicare or Medicaid claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Reimbursement Rate
Situational
2
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MOA02 is the claim Health Care Financing Administration Common Procedural Coding System (HCPCS) payable amount.
SITUATIONAL RULE: Required when the outpatient institutional claim HCPCS Payable Amount is not zero for a Medicare or Medicaid claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim HCPCS Payable Amount
Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Situational
3
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MOA03 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when a Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
4
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MOA04 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
5
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MOA05 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
6
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MOA06 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
7
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: MOA07 is the Claim Payment Remark Code. See Code Source 411.
SITUATIONAL RULE: Required when an additional Claim Payment Remark Code applies to this entire claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Payment Remark Code
Situational
8
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MOA08 is the End Stage Renal Disease (ESRD) payment amount.
SITUATIONAL RULE: Required when the outpatient institutional claim ESRD Payment Amount is not zero for a Medicare or Medicaid claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim ESRD Payment Amount
Situational
9
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MOA09 is the professional component amount billed but not payable.
SITUATIONAL RULE: Required when the outpatient institutional claim Nonpayable Professional Component Amount is not zero for a Medicare or Medicaid claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Nonpayable Professional Component Amount

REF - OTHER CLAIM RELATED IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
5
Situational Rule:
Required when additional reference numbers specific to the claim in the CLP segment are provided to identify information used in the process of adjudicating this claim. If not required by this implementation guide, do not send.
TR3 Example:
REF✱EA✱666123~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
1L
Group or Policy Number
Use this code when conveying the Group Number in REF02.
1W
Member Identification Number
28
Employee Identification Number
6P
Group Number
This is the Other Insured Group Number. This is required when a Corrected Priority Payer is identified in the NM1 segment and the Group Number of the other insured for that payer is known.
9A
Repriced Claim Reference Number
9C
Adjusted Repriced Claim Reference Number
BB
Authorization Number
Use this qualifier only when supplying an authorization number that was assigned by the adjudication process and was not provided prior to the services. Do not use this qualifier when reporting the same number as reported in the claim as the prior authorization or pre-authorization number.
CE
Class of Contract Code
See section 1.10.2.15 for information on the use of Class of Contract Code.
EA
Medical Record Identification Number
F8
Original Reference Number
When this is a correction claim and CLP07 does not equal the CLP07 value from the original claim payment, one iteration of this REF segment using this qualifier is REQUIRED to identify the original claim CLP07 value in REF02. See section 1.10.2.8, Reversals and Corrections, for additional information.
G1
Prior Authorization Number
Use this qualifier when reporting the number received with the original claim as a pre-authorization number (in the 837 that was at table 2, position 180, REF segment, using the same qualifier of G1).
G3
Predetermination of Benefits Identification Number
IG
Insurance Policy Number
Use this code when conveying the Policy Number in REF02.
SY
Social Security Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Other Claim Related Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - RENDERING PROVIDER IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
10
Situational Rule:
Required when additional rendering provider identification numbers not already reported in the Provider NM1 segment for this claim were submitted on the original claim and impacted adjudication. If not required by this implementation guide, do not send.
TR3 Notes:
The NM1 segment always contains the primary reference number.
TR3 Example:
REF✱1C✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
1A
Blue Cross Provider Number
1B
Blue Shield Provider Number
1C
Medicare Provider Number
1D
Medicaid Provider Number
1G
Provider UPIN Number
1H
CHAMPUS Identification Number
1J
Facility ID Number
D3
National Council for Prescription Drug Programs Pharmacy Number
CODE SOURCE 307: National Council for Prescription Drug Programs Pharmacy Number
G2
Provider Commercial Number
LU
Location Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Rendering Provider Secondary Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

DTM - STATEMENT FROM OR TO DATE

X12 Name:
Date/Time Reference
X12 Purpose:
To specify pertinent dates and times
X12 Syntax:
  1. R020305
    At least one of DTM02, DTM03 or DTM05 is required.
  2. C0403
    If DTM04 is present, then DTM03 is required.
  3. P0506
    If either DTM05 or DTM06 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when the "Statement From or To Dates" are not supplied at the service (2110 loop) level. If not required by this implementation guide, may be provided at senders discretion, but cannot be required by the receiver.
TR3 Notes:
  1. Dates at the claim level apply to the entire claim, including all service lines. Dates at the service line level apply only to the service line where they appear.
  2. When claim dates are not provided, service dates are required for every service line.
  3. When claim dates are provided, service dates are not required, but if used they override the claim dates for individual service lines.
  4. For retail pharmacy claims, the Claim Statement Period Start Date is equivalent to the prescription filled date.
  5. For predeterminations, where there is no service date, the value of DTM02 must be 19000101. Use only when the CLP02 value is 25 - Predetermination Pricing Only - No Payment.
  6. When payment is being made in advance of services, the use of future dates is allowed.
TR3 Example:
DTM✱233✱20020916~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
232
Claim Statement Period Start
If the claim statement period start date is conveyed without a subsequent claim statement period end date, the end date is assumed to be the same as the start date. This date or code 233 is required when service level dates are not provided in the remittance advice.
233
Claim Statement Period End
If a claim statement period end date is conveyed without a claim statement period start date, then the start date is assumed to be different from the end date but not conveyed at the payer's discretion. See the note on code 232.
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Claim Date
Not Used
3
337
Time
O 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
O 1
ID
2/3
Not Used
6
1251
Date Time Period
O 1
AN
1/35

DTM*036 - COVERAGE EXPIRATION DATE

X12 Name:
Date/Time Reference
X12 Purpose:
To specify pertinent dates and times
X12 Syntax:
  1. R020305
    At least one of DTM02, DTM03 or DTM05 is required.
  2. C0403
    If DTM04 is present, then DTM03 is required.
  3. P0506
    If either DTM05 or DTM06 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when payment is denied because of the expiration of coverage. If not required by this implementation guide, do not send.
TR3 Example:
DTM✱036✱20011001~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
036
Expiration
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
This is the expiration date of the patient's coverage.
Not Used
3
337
Time
O 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
O 1
ID
2/3
Not Used
6
1251
Date Time Period
O 1
AN
1/35

DTM*050 - CLAIM RECEIVED DATE

X12 Name:
Date/Time Reference
X12 Purpose:
To specify pertinent dates and times
X12 Syntax:
  1. R020305
    At least one of DTM02, DTM03 or DTM05 is required.
  2. C0403
    If DTM04 is present, then DTM03 is required.
  3. P0506
    If either DTM05 or DTM06 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required whenever state or federal regulations or the provider contract mandate interest payment or prompt payment discounts based upon the receipt date of the claim by the payer. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
TR3 Example:
DTM✱050✱20011124~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
050
Received
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
This is the date that the claim was received by the payer.
Not Used
3
337
Time
O 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
O 1
ID
2/3
Not Used
6
1251
Date Time Period
O 1
AN
1/35

PER*CX - CLAIM CONTACT INFORMATION

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when there is a claim specific communications contact. If not required by this implementation guide, do not send.
TR3 Notes:
When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number always includes the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (800)555-1212 would be represented as 8005551212). The extension number, when applicable, is identified in the next element pair (Communications Number Qualifier and Communication Number) immediately after the telephone number.
TR3 Example:
PER✱CX✱✱TE✱8005551212~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
CX
Payers Claim Office
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when the name of the individual to contact is not already defined or is different than the name within the prior contact segment (PER). If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Name
Required
3
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Required
4
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Claim Contact Communications Number
Situational
5
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when required per ASC X12 syntax when PER06 is sent. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
When used, the value following this code is the extension for the preceding communications contact number.
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when a second claim specific communications contact number exists. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Communications Number
Situational
7
365
Communication Number Qualifier
O 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when required per ASC X12 syntax when PER08 is sent. If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Situational
8
364
Communication Number
O 1
AN
1/256
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
INDUSTRY NAME: Communication Number Extension
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

AMT - CLAIM SUPPLEMENTAL INFORMATION

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
13
Situational Rule:
Required when the value of any specific amount identified by the AMT01 qualifier is non-zero. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Use this segment to convey information only. It is not part of the financial balancing of the 835.
  2. Send/receive one AMT for each applicable non-zero value. Do not report any zero values.
TR3 Example:
AMT✱T✱49~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
AU
Coverage Amount
Use this monetary amount to report the total covered charges.

This is the sum of the original submitted provider charges that are considered for payment under the benefit provisions of the health plan. This excludes charges considered not covered (i.e. per day television or telephone charges) but includes reductions to payments of covered services (i.e. reductions for amounts over fee schedule and patient deductibles).
D8
Discount Amount
Prompt Pay Discount Amount

See section 1.10.2.9 for additional information.
DY
Per Day Limit
F5
Patient Amount Paid
Use this monetary amount for the amount the patient has already paid.
I
Interest
See section 1.10.2.9 for additional information.
NL
Negative Ledger Balance
Used only by Medicare Part A and Medicare Part B.
T
Tax
T2
Total Claim Before Taxes
Used only when tax also applies to the claim.
ZK
Federal Medicare or Medicaid Payment Mandate - Category 1
ZL
Federal Medicare or Medicaid Payment Mandate - Category 2
ZM
Federal Medicare or Medicaid Payment Mandate - Category 3
ZN
Federal Medicare or Medicaid Payment Mandate - Category 4
ZO
Federal Medicare or Medicaid Payment Mandate - Category 5
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Claim Supplemental Information Amount
Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

QTY - CLAIM SUPPLEMENTAL INFORMATION QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
14
Situational Rule:
Required when the value of a specific quantity identified by the QTY01 qualifier is non-zero. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Use this segment to convey information only. It is not part of the financial balancing of the 835.
  2. Send one QTY for each non-zero value. Do not report any zero values.
TR3 Example:
QTY✱ZK✱3~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
CA
Covered - Actual
CD
Co-insured - Actual
LA
Life-time Reserve - Actual
LE
Life-time Reserve - Estimated
NE
Non-Covered - Estimated
NR
Not Replaced Blood Units
OU
Outlier Days
PS
Prescription
VS
Visits
ZK
Federal Medicare or Medicaid Payment Mandate - Category 1
ZL
Federal Medicare or Medicaid Payment Mandate - Category 2
ZM
Federal Medicare or Medicaid Payment Mandate - Category 3
ZN
Federal Medicare or Medicaid Payment Mandate - Category 4
ZO
Federal Medicare or Medicaid Payment Mandate - Category 5
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Claim Supplemental Information Quantity
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

SVC - SERVICE PAYMENT INFORMATION

X12 Name:
Service Information
X12 Purpose:
To supply payment and control information to a provider for a particular service
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required for all service lines in a professional, dental or outpatient claim priced at the service line level or whenever payment for any service line of the claim is different than the original submitted charges due to service line specific adjustments (excluding cases where the only service specific adjustment is for room per diem). If not required by this implementation guide, do not send.
TR3 Notes:
  1. See section 1.10.2.1.1 (Service Line Balancing) for additional information.
  2. The exception to the situational rule occurs with institutional claims when the room per diem is the only service line adjustment. In this instance, a claim level CAS adjustment to the per diem is appropriate (i.e., CAS*CO*78*25~). See section 1.10.2.4.1 for additional information.
  3. See 1.10.2.6, Procedure Code Bundling and Unbundling, and section 1.10.2.1.1, Service Line Balancing, for important SVC segment usage information.
TR3 Example:
SVC✱HC:99214✱100✱80~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C003
Composite Medical Procedure Identifier
M 1
To identify a medical procedure by its standardized codes and applicable modifiers
SEMANTIC: SVC01 is the medical procedure upon which adjudication is based.
COMMENT: For Medicare Part A claims, SVC01 would be the Health Care Financing Administration (HCFA) Common Procedural Coding System (HCPCS) Code (see code source 130) and SVC04 would be the Revenue Code (see code source 132).
X12 COMPOSITE SEMANTIC NOTES:
  1. C003-01 qualifies C003-02 and C003-08.
  2. If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
  3. C003-03 modifies the value in C003-02 and C003-08.
  4. C003-04 modifies the value in C003-02 and C003-08.
  5. C003-05 modifies the value in C003-02 and C003-08.
  6. C003-06 modifies the value in C003-02 and C003-08.
  7. C003-07 is the description of the procedure identified in C003-02.
  8. C003-08 represents the ending value in the range in which the code occurs.
  1. This is the adjudicated medical procedure information.
  2. This code is a composite data structure.
Required
1-1
235
Product/Service ID Qualifier
M 1
ID
2
Code identifying the type/source of the descriptive number used in Product/Service ID (234)
INDUSTRY NAME: Product or Service ID Qualifier
The value in SVC01-1 qualifies the values in SVC01-2, SVC01-3, SVC01-4, SVC01-5, SVC01-6 and SVC01-7.
CODE
DEFINITION
AD
American Dental Association Codes
CODE SOURCE 135: American Dental Association
ER
Jurisdiction Specific Procedure and Supply Codes
CODE SOURCE 576: Workers Compensation Specific Procedure and Supply Codes
HC
Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes
Because the CPT codes of the American Medical Association are also level 1 HCPCS codes, they are reported under the code HC.
CODE SOURCE 130: Healthcare Common Procedural Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code
Medicare uses this code to reflect the Skilled Nursing Facility Group as well as the Home Health Agency Outpatient Prospective Payment System.
CODE SOURCE 716: Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities
IV
Home Infusion EDI Coalition (HIEC) Product/Service Code
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used 1) If a new rule names HIEC as an allowable code set under HIPAA. 2) For Property & Casualty claims/encounters that are not covered under HIPAA.
CODE SOURCE 513: Home Infusion EDI Coalition (HIEC) Product/Service Code List
N4
National Drug Code in 5-4-2 Format
CODE SOURCE 240: National Drug Code by Format
N6
National Health Related Item Code in 4-6 Format
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used 1) If a new rule names National Health Related Item Code in 4-6 Format Codes as an allowable code set under HIPAA. 2) For Property & Casualty claims/encounters that are not covered under HIPAA.
CODE SOURCE 240: National Drug Code by Format
NU
National Uniform Billing Committee (NUBC) UB92 Codes
CODE SOURCE 132: National Uniform Billing Committee (NUBC) Codes
UI
U.P.C. Consumer Package Code (1-5-5)
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used 1) If a new rule names U.P.C. Consumer Package Code (1-5-5) Codes as an allowable code set under HIPAA. 2) For Property & Casualty claims/encounters that are not covered under HIPAA.
WK
Advanced Billing Concepts (ABC) Codes
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used in transactions covered under HIPAA by parties registered in the pilot project and their trading partners.
CODE SOURCE 843: Advanced Billing Concepts (ABC) Codes
Required
1-2
234
Product/Service ID
M 1
AN
1/48
Identifying number for a product or service
INDUSTRY NAME: Adjudicated Procedure Code
This is the adjudicated procedure code or revenue code as identified by the qualifier in SVC01-1.
Situational
1-3
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-4
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a second procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-5
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a third procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-6
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a fourth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Not Used
1-7
352
Description
O 1
AN
1/80
Not Used
1-8
234
Product/Service ID
O 1
AN
1/48
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: SVC02 is the submitted service charge.
INDUSTRY NAME: Line Item Charge Amount
  1. Use this monetary amount for the submitted service charge amount.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Required
3
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: SVC03 is the amount paid this service.
INDUSTRY NAME: Line Item Provider Payment Amount
Use this number for the service amount paid. The value in SVC03 must equal the value in SVC02 minus all monetary amounts in the subsequent CAS segments of this loop. See 1.10.2.1, Balancing, for additional information.
Situational
4
234
Product/Service ID
O 1
AN
1/48
Identifying number for a product or service
SEMANTIC: SVC04 is the National Uniform Billing Committee Revenue Code.
SITUATIONAL RULE: Required when an NUBC revenue code was considered during adjudication in addition to a procedure code already identified in SVC01. If not required by this implementation guide, do not send.
INDUSTRY NAME: National Uniform Billing Committee Revenue Code
If the original claim and adjudication only referenced an NUBC revenue code, that is supplied in SVC01 and this element is not used.
Situational
5
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: SVC05 is the paid units of service.
SITUATIONAL RULE: Required when the paid units of service are different than one. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Units of Service Paid Count
If not present, the value is assumed to be one.
Situational
6
C003
Composite Medical Procedure Identifier
O 1
To identify a medical procedure by its standardized codes and applicable modifiers
SEMANTIC: SVC06 is the original submitted medical procedure.
X12 COMPOSITE SEMANTIC NOTES:
  1. C003-01 qualifies C003-02 and C003-08.
  2. If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
  3. C003-03 modifies the value in C003-02 and C003-08.
  4. C003-04 modifies the value in C003-02 and C003-08.
  5. C003-05 modifies the value in C003-02 and C003-08.
  6. C003-06 modifies the value in C003-02 and C003-08.
  7. C003-07 is the description of the procedure identified in C003-02.
  8. C003-08 represents the ending value in the range in which the code occurs.
SITUATIONAL RULE: Required when the adjudicated procedure code provided in SVC01 is different from the submitted procedure code from the original claim. If not required by this implementation guide, do not send.
  1. This code is a composite data structure.
  2. This is the Submitted Procedure Code information.
Required
6-1
235
Product/Service ID Qualifier
M 1
ID
2
Code identifying the type/source of the descriptive number used in Product/Service ID (234)
INDUSTRY NAME: Product or Service ID Qualifier
The value in SVC06-1 qualifies the value in SVC06-2, SVC06-3, SVC06-4, SVC06-5, SVC06-6 and SVC06-7.
CODE
DEFINITION
AD
American Dental Association Codes
CODE SOURCE 135: American Dental Association
ER
Jurisdiction Specific Procedure and Supply Codes
CODE SOURCE 576: Workers Compensation Specific Procedure and Supply Codes
HC
Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes
Because the CPT codes of the American Medical Association are also level 1 HCPCS codes, they are reported under the code HC.
CODE SOURCE 130: Healthcare Common Procedural Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code
Medicare uses this code to reflect the Skilled Nursing Facility Group as well as the Home Health Agency Outpatient Prospective Payment System.
CODE SOURCE 716: Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities
IV
Home Infusion EDI Coalition (HIEC) Product/Service Code
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used 1) If a new rule names HIEC as an allowable code set under HIPAA. 2) For Property & Casualty claims/encounters that are not covered under HIPAA.
CODE SOURCE 513: Home Infusion EDI Coalition (HIEC) Product/Service Code List
N4
National Drug Code in 5-4-2 Format
CODE SOURCE 240: National Drug Code by Format
NU
National Uniform Billing Committee (NUBC) UB92 Codes
CODE SOURCE 132: National Uniform Billing Committee (NUBC) Codes
WK
Advanced Billing Concepts (ABC) Codes
This qualifier can only be used in transactions covere under HIPAA by parties registered in the pilot project and their trading partners.
CODE SOURCE 843: Advanced Billing Concepts (ABC) Codes
Required
6-2
234
Product/Service ID
M 1
AN
1/48
Identifying number for a product or service
INDUSTRY NAME: Procedure Code
Situational
6-3
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-4
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a second procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-5
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a third procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-6
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when a fourth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-7
352
Description
O 1
AN
1/80
A free-form description to clarify the related data elements and their content
SITUATIONAL RULE: Required when a description was received on the original service for a not otherwise classified procedure code. If not required by this implementation guide, do not send.
INDUSTRY NAME: Procedure Code Description
Not Used
6-8
234
Product/Service ID
O 1
AN
1/48
Situational
7
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: SVC07 is the original submitted units of service.
SITUATIONAL RULE: Required when the paid units of service provided in SVC05 is different from the submitted units of service from the original claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Original Units of Service Count

DTM - SERVICE DATE

X12 Name:
Date/Time Reference
X12 Purpose:
To specify pertinent dates and times
X12 Syntax:
  1. R020305
    At least one of DTM02, DTM03 or DTM05 is required.
  2. C0403
    If DTM04 is present, then DTM03 is required.
  3. P0506
    If either DTM05 or DTM06 is present, then the other is required.
X12 Set Notes:
NOTE: The DTM segment in the SVC loop is to be used to express dates and date ranges specifically related to the service identified in the SVC segment.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when claim level Statement From or Through Dates are not supplied or the service dates are not the same as reported at the claim level. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
TR3 Notes:
  1. Dates at the service line level apply only to the service line where they appear.
  2. If used for inpatient claims and no service date was provided on the claim then report the through date from the claim level.
  3. When claim dates are not provided, service dates are required for every service line.
  4. When claim dates are provided, service dates are not required, but if used they override the claim dates for individual service lines.
  5. For retail pharmacy claims, the service date is equivalent to the prescription filled date.
  6. For predeterminations, where there is no service date, the value of DTM02 must be 19000101. Use only when the CLP02 value is 25 - Predetermination Pricing Only - No Payment.
  7. When payment is being made in advance of services, the use of future dates is allowed.
TR3 Example:
DTM✱472✱20021031~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
150
Service Period Start
This qualifier is required for reporting the beginning of multi-day services. If not required by this implementation guide, do not send.
151
Service Period End
This qualifier is required for reporting the end of multi-day services. If not required by this implementation guide, do not send.
472
Service
This qualifier is required to indicate a single day service. If not required by this implementation guide, do not send.
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Service Date
Not Used
3
337
Time
O 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
O 1
ID
2/3
Not Used
6
1251
Date Time Period
O 1
AN
1/35

CAS - SERVICE ADJUSTMENT

X12 Name:
Claims Adjustment
X12 Purpose:
To supply adjustment reason codes and amounts as needed for an entire claim or for a particular service within the claim being paid
X12 Syntax:
  1. L050607
    If CAS05 is present, then at least one of CAS06 or CAS07 are required.
  2. C0605
    If CAS06 is present, then CAS05 is required.
  3. C0705
    If CAS07 is present, then CAS05 is required.
  4. L080910
    If CAS08 is present, then at least one of CAS09 or CAS10 are required.
  5. C0908
    If CAS09 is present, then CAS08 is required.
  6. C1008
    If CAS10 is present, then CAS08 is required.
  7. L111213
    If CAS11 is present, then at least one of CAS12 or CAS13 are required.
  8. C1211
    If CAS12 is present, then CAS11 is required.
  9. C1311
    If CAS13 is present, then CAS11 is required.
  10. L141516
    If CAS14 is present, then at least one of CAS15 or CAS16 are required.
  11. C1514
    If CAS15 is present, then CAS14 is required.
  12. C1614
    If CAS16 is present, then CAS14 is required.
  13. L171819
    If CAS17 is present, then at least one of CAS18 or CAS19 are required.
  14. C1817
    If CAS18 is present, then CAS17 is required.
  15. C1917
    If CAS19 is present, then CAS17 is required.
X12 Set Notes:
NOTE: The CAS segment is used to reflect changes to amounts within Table 2.
X12 Comments:
Adjustment information is intended to help the provider balance the remittance information. Adjustment amounts should fully explain the difference between submitted charges and the amount paid.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
99
Situational Rule:
Required when dollar amounts are being adjusted specific to the service or when the paid amount for a service line (SVC03) is different than the original submitted charge amount for the service (SVC02). If not required by this implementation guide, do not send.
TR3 Notes:
  1. An example of this level of CAS is the reduction for the part of the service charge that exceeds the usual and customary charge for the service. See sections 1.10.2.1, Balancing, and 1.10.2.4, Claim Adjustment and Service Adjustment Segment Theory, for additional information.
  2. A single CAS segment contains six repetitions of the "adjustment trio" composed of adjustment reason code, adjustment amount, and adjustment quantity. These six adjustment trios are used to report up to six adjustments related to a specific Claim Adjustment Group Code (CAS01). The six iterations (trios) of the Adjustment Reason Code related to the Specific Adjustment Group Code must be exhausted before repeating a second iteration of the CAS segment using the same Adjustment Group Code. The first adjustment is reported in the first adjustment trio (CAS02-CAS04). If there is a second non-zero adjustment, it is reported in the second adjustment trio (CAS05-CAS07), and so on through the sixth adjustment trio (CAS17-CAS19).
TR3 Example:
CAS✱PR✱1✱793✱✱3✱25~CAS✱CO✱131✱250~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1033
Claim Adjustment Group Code
M 1
ID
1/2
Code identifying the general category of payment adjustment
Evaluate the usage of group codes in CAS01 based on the following order for their applicability to a set of one or more adjustments: PR, CO, PI, OA. See 1.10.2.4, Claim Adjustment and Service Adjustment Segment Theory, for additional information. (Note: This does not mean that the adjustments must be reported in this order.)
CODE
DEFINITION
CO
Contractual Obligations
Use this code when a joint payer/payee agreement or a regulatory requirement has resulted in an adjustment.
OA
Other adjustments
Avoid using the Other Adjustment Group Code (OA) except for business situations described in sections 1.10.2.6, 1.10.2.7 and 1.10.2.13.
PI
Payor Initiated Reductions
Use this code when, in the opinion of the payer, the adjustment is not the responsibility of the patient, but there is no supporting contract between the provider and the payer (i.e., medical review or professional review organization adjustments).
PR
Patient Responsibility
Required
2
1034
Claim Adjustment Reason Code
M 1
ID
1/5
Code identifying the detailed reason the adjustment was made
INDUSTRY NAME: Adjustment Reason Code
Required to report a non-zero adjustment applied at the service level for the claim adjustment group code reported in CAS01.
CODE SOURCE 139:Claim Adjustment Reason Code
Required
3
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: CAS03 is the amount of adjustment.
INDUSTRY NAME: Adjustment Amount
  1. Use this monetary amount for the adjustment amount. A negative amount increases the payment, and a positive amount decreases the payment contained in SVC03 and CLP04.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Situational
4
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS04 is the units of service being adjusted.
SITUATIONAL RULE: Required when units of service are being adjusted. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
A positive number decreases paid units, and a negative value increases paid units.
Situational
5
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L050607, C0605, C0705
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the service for the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
See CAS02.
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS06 is the amount of the adjustment.
SEGMENT SYNTAX: L050607, C0605
SITUATIONAL RULE: Required when CAS05 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
7
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS07 is the units of service being adjusted.
SEGMENT SYNTAX: L050607, C0705
SITUATIONAL RULE: Required when CAS05 is present and is related to a units of service adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
8
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L080910, C0908, C1008
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the service for the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
See CAS02.
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
9
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS09 is the amount of the adjustment.
SEGMENT SYNTAX: L080910, C0908
SITUATIONAL RULE: Required when CAS08 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
10
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS10 is the units of service being adjusted.
SEGMENT SYNTAX: L080910, C1008
SITUATIONAL RULE: Required when CAS08 is present and is related to a units of service adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
11
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L111213, C1211, C1311
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the service for the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
See CAS02.
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
12
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS12 is the amount of the adjustment.
SEGMENT SYNTAX: L111213, C1211
SITUATIONAL RULE: Required when CAS11 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
13
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS13 is the units of service being adjusted.
SEGMENT SYNTAX: L111213, C1311
SITUATIONAL RULE: Required when CAS11 is present and is related to a units of service adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
14
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L141516, C1514, C1614
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the service for the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
See CAS02.
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
15
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS15 is the amount of the adjustment.
SEGMENT SYNTAX: L141516, C1514
SITUATIONAL RULE: Required when CAS14 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
16
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS16 is the units of service being adjusted.
SEGMENT SYNTAX: L141516, C1614
SITUATIONAL RULE: Required when CAS14 is present and is related to a units of service adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.
Situational
17
1034
Claim Adjustment Reason Code
O 1
ID
1/5
Code identifying the detailed reason the adjustment was made
SEGMENT SYNTAX: L171819, C1817, C1917
SITUATIONAL RULE: Required when an additional non-zero adjustment, beyond what has already been supplied, applies to the service for the claim adjustment group code used in CAS01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Reason Code
See CAS02.
CODE SOURCE 139:Claim Adjustment Reason Code
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CAS18 is the amount of the adjustment.
SEGMENT SYNTAX: L171819, C1817
SITUATIONAL RULE: Required when CAS17 is present. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Amount
See CAS03.
Situational
19
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: CAS19 is the units of service being adjusted.
SEGMENT SYNTAX: L171819, C1917
SITUATIONAL RULE: Required when CAS17 is present and is related to a units of service adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
See CAS04.

REF - SERVICE IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
8
Situational Rule:
Required when related service specific reference identifiers were used in the process of adjudicating this service. If not required by this implementation guide, do not send.
TR3 Example:
REF✱RB✱100~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
1S
Ambulatory Patient Group (APG) Number
APC
Ambulatory Payment Classification
CODE SOURCE 468: Ambulatory Payment Classification
BB
Authorization Number
E9
Attachment Code
G1
Prior Authorization Number
G3
Predetermination of Benefits Identification Number
LU
Location Number
This is the Payer's identification for the provider location. This is REQUIRED when the specific site of service affected the payment of the claim.
RB
Rate code number
Rate Code Number reflects Ambulatory Surgical Center (ASC) rate for Medicare, either 0, 50, 100 or 150%.
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Provider Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*6R - LINE ITEM CONTROL NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a Line Item Control Number was received on the original claim or when claim or service line splitting has occurred. If not required by this implementation guide, do not send.
TR3 Notes:
This is the Line Item Control Number submitted in the 837, which is utilized by the provider for tracking purposes. See section 1.10.2.11 and 1.10.2.14.1 for additional information on usage with split claims or services. Note - the value in REF02 can include alpha characters.
TR3 Example:
REF✱6R✱A78910~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
6R
Provider Control Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Line Item Control Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - RENDERING PROVIDER INFORMATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
10
Situational Rule:
Required when the rendering provider for this service is different than the rendering provider applicable at the claim level. If not required by this implementation guide, do not send.
TR3 Example:
REF✱HPI✱1234567891~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
1A
Blue Cross Provider Number
1B
Blue Shield Provider Number
1C
Medicare Provider Number
1D
Medicaid Provider Number
1G
Provider UPIN Number
1H
CHAMPUS Identification Number
1J
Facility ID Number
D3
National Council for Prescription Drug Programs Pharmacy Number
CODE SOURCE 307: National Council for Prescription Drug Programs Pharmacy Number
G2
Provider Commercial Number
HPI
Centers for Medicare and Medicaid Services National Provider Identifier
This qualifier is REQUIRED when the National Provider Identifier is mandated for use and the provider is a covered health care provider under that mandate.
CODE SOURCE 537: Centers for Medicare and Medicaid Services National Provider Identifier
SY
Social Security Number
TJ
Federal Taxpayer's Identification Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Rendering Provider Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*0K - HEALTHCARE POLICY IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
5
Situational Rule:
Required when;
• The payment is adjusted in accordance with the Payer's published Healthcare Policy Code list and
• A Claim Adjustment Reason Code identified by the notation, "refer to 835 Healthcare Policy identification segment", in the Claim Adjustment Reason Code List is present in a related CAS segment and
• The payer has a published enumerated healthcare policy code list available to healthcare providers via an un-secure public website and
• The payer wishes to supply this policy detail to reduce provider inquiries.

If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
  1. Healthcare Policy - A clinical/statutory rule use to determine claim adjudication that cannot be explained by the sole use of a claim adjustment reason code in the CAS segment and Remittance Advise Remark code when appropriate.
  2. The term Healthcare Policy is intended to include Medical Review Policy, Dental Policy Review, Property and Casualty Policies, Workers Comp Policies and Pharmacy Policies for example Medicare LMRP's.( Local Medicare Review policies) and NCD (National Coverage Determinations).
  3. This policy segment must not be used to provide a proprietary explanation code or reason for adjustment.
  4. Supply the Healthcare policy identifier in REF02 as provided by the payer's published Healthcare policy code list. This policy code will be used to explain the policy used to process the claim which resulted in the adjusted payment.
  5. If this segment is used, the PER (Payer Web Site) segment is required to provide an un-secure WEB contact point where the provider can access the payer's enumerated, published healthcare policy.
TR3 Example:
REF✱0K✱L12345678910~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0K
Policy Form Identifying Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Healthcare Policy Identification
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

AMT - SERVICE SUPPLEMENTAL AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
9
Situational Rule:
Required when the value of any specific amount identified by the AMT01 qualifier is non-zero. If not required by this implementation guide, do not send.
TR3 Notes:
This segment is used to convey information only. It is not part of the financial balancing of the 835.
TR3 Example:
AMT✱B6✱425~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
B6
Allowed - Actual
Allowed amount is the amount the payer deems payable prior to considering patient responsibility.
KH
Deduction Amount
Late Filing Reduction
T
Tax
T2
Total Claim Before Taxes
Use this monetary amount for the service charge before taxes. This is only used when there is an applicable tax amount on this service.
ZK
Federal Medicare or Medicaid Payment Mandate - Category 1
ZL
Federal Medicare or Medicaid Payment Mandate - Category 2
ZM
Federal Medicare or Medicaid Payment Mandate - Category 3
ZN
Federal Medicare or Medicaid Payment Mandate - Category 4
ZO
Federal Medicare or Medicaid Payment Mandate - Category 5
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Service Supplemental Amount
Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

QTY - SERVICE SUPPLEMENTAL QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
6
Situational Rule:
Required when new Federal Medicare or Medicaid mandates require Quantity counts and value of specific quantities identified in the QTY01 qualifier are non-zero. If not required by this implementation guide, do not send.
TR3 Notes:
Use this segment to convey information only. It is not part of the financial balancing of the 835.
TR3 Example:
QTY✱ZL✱3.75~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
ZK
Federal Medicare or Medicaid Payment Mandate - Category 1
ZL
Federal Medicare or Medicaid Payment Mandate - Category 2
ZM
Federal Medicare or Medicaid Payment Mandate - Category 3
ZN
Federal Medicare or Medicaid Payment Mandate - Category 4
ZO
Federal Medicare or Medicaid Payment Mandate - Category 5
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Service Supplemental Quantity Count
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

LQ - HEALTH CARE REMARK CODES

X12 Name:
Industry Code Identification
X12 Purpose:
To identify standard industry codes
X12 Syntax:
C0102
If LQ01 is present, then LQ02 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
99
Situational Rule:
Required when remark codes or NCPDP Reject/Payment codes are necessary for the provider to fully understand the adjudication message for a given service line. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
Use this segment to provide informational remarks only. This segment has no impact on the actual payment. Changes in claim payment amounts are provided in the CAS segments.
TR3 Example:
LQ✱HE✱12345~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1270
Code List Qualifier Code
O 1
ID
1/3
Code identifying a specific industry code list
SEGMENT SYNTAX: C0102
CODE
DEFINITION
HE
Claim Payment Remark Codes
CODE SOURCE 411: Remittance Advice Remark Codes
RX
National Council for Prescription Drug Programs Reject/Payment Codes
CODE SOURCE 530: National Council for Prescription Drug Programs Reject/Payment Codes
Required
2
1271
Industry Code
O 1
AN
1/30
Code indicating a code from a specific industry code list
SEGMENT SYNTAX: C0102
INDUSTRY NAME: Remark Code

PLB - PROVIDER ADJUSTMENT

X12 Name:
Provider Level Adjustment
X12 Purpose:
To convey provider level adjustment information for debit or credit transactions such as, accelerated payments, cost report settlements for a fiscal year and timeliness report penalties unrelated to a specific claim or service
X12 Syntax:
  1. P0506
    If either PLB05 or PLB06 is present, then the other is required.
  2. P0708
    If either PLB07 or PLB08 is present, then the other is required.
  3. P0910
    If either PLB09 or PLB10 is present, then the other is required.
  4. P1112
    If either PLB11 or PLB12 is present, then the other is required.
  5. P1314
    If either PLB13 or PLB14 is present, then the other is required.
Segment Usage:
Situational
Segment Repeat:
>1
Situational Rule:
Required when reporting adjustments to the actual payment that are NOT specific to a particular claim or service. If not required by this implementation guide, do not send.
TR3 Notes:
  1. These adjustments can either decrease the payment (a positive number) or increase the payment (a negative number). Zero dollar adjustments are not allowed. Some examples of PLB adjustments are a Periodic Interim Payment (loans and loan repayment) or a capitation payment. Multiple adjustments can be placed in one PLB segment, grouped by the provider identified in PLB01 and the period identified in PLB02. Although the PLB reference numbers are not standardized, refer to 1.10.2.9 (Interest and Prompt Payment Discounts), 1.10.2.10 (Capitation and Related Payments or Adjustments), 1.10.2.12 (Balance Forward Processing), 1.10.2.16 (Post Payment Recovery) and 1.10.2.17 (Claim Overpayment Recovery) for code suggestions and usage guidelines.
  2. The codes and notations under PLB03 and its components apply equally to PLB05, 07, 09, 11 and 13.
TR3 Example:
PLB✱1234567890✱20000930✱CV:9876514✱-1.27~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: PLB01 is the provider number assigned by the payer.
INDUSTRY NAME: Provider Identifier
  1. When the National Provider Identifier (NPI) is mandated and the provider is a covered health care provider under that mandate, this must be the NPI assigned to the provider.
  2. Until the NPI is mandated, this is the provider identifier as assigned by the payer.
Required
2
373
Date
M 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: PLB02 is the last day of the provider's fiscal year.
INDUSTRY NAME: Fiscal Period Date
This is the last day of the provider's fiscal year. If the end of the provider's fiscal year is not known by the payer, use December 31st of the current year.
Required
3
C042
Adjustment Identifier
M 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB03 is the adjustment information as defined by the payer.
This identifier is a composite data structure. The composite identifies the reason and identifying information for the related adjustment dollar amount (PLB04 for PLB03).
Required
3-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
3-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Use when necessary to assist the receiver in identifying, tracking or reconcilling the adjustment. See sections 1.10.2.10 (Capitation and Related Payments), 1.10.2.5 (Advanced Payments and Reconciliation) and 1.10.2.12 (Balance Forward Processing) for further information.
Required
4
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: PLB04 is the adjustment amount.
INDUSTRY NAME: Provider Adjustment Amount
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Decimal elements will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). This applies to all subsequent 782 elements.
Situational
5
C042
Adjustment Identifier
O 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB05 is the adjustment information as defined by the payer.
SITUATIONAL RULE: Required when an additional adjustment not already reported applies to this remittance advice. If not required by this implementation guide, do not send.
See PLB03 for details.
Required
5-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
5-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: PLB06 is the adjustment amount.
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when PLB05 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Amount
This is the adjustment amount for the preceding adjustment reason.
Situational
7
C042
Adjustment Identifier
O 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB07 is adjustment information as defined by the payer.
SITUATIONAL RULE: Required when an additional adjustment not already reported applies to this remittance advice. If not required by this implementation guide, do not send.
See PLB03 for details.
Required
7-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
7-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Situational
8
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: PLB08 is the adjustment amount.
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when PLB07 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Amount
This is the adjustment amount for the preceding adjustment reason.
Situational
9
C042
Adjustment Identifier
O 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB09 is adjustment information as defined by the payer.
SITUATIONAL RULE: Required when an additional adjustment not already reported applies to this remittance advice. If not required by this implementation guide, do not send.
See PLB03 for details.
Required
9-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
9-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Situational
10
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: PLB10 is the adjustment amount.
SEGMENT SYNTAX: P0910
SITUATIONAL RULE: Required when PLB09 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Amount
This is the adjustment amount for the preceding adjustment reason.
Situational
11
C042
Adjustment Identifier
O 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB11 is adjustment information as defined by the payer.
SITUATIONAL RULE: Required when an additional adjustment not already reported applies to this remittance advice. If not required by this implementation guide, do not send.
See PLB03 for details.
Required
11-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
11-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Situational
12
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: PLB12 is the adjustment amount.
SEGMENT SYNTAX: P1112
SITUATIONAL RULE: Required when PLB11 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Amount
This is the adjustment amount for the preceding adjustment reason.
Situational
13
C042
Adjustment Identifier
O 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB13 is adjustment information as defined by the payer.
SITUATIONAL RULE: Required when an additional adjustment not already reported applies to this remittance advice. If not required by this implementation guide, do not send.
See PLB03 for details.
Required
13-1
426
Adjustment Reason Code
M 1
ID
2
Code indicating reason for debit or credit memo or adjustment to invoice, debit or credit memo, or payment
CODE
DEFINITION
50
Late Charge
This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty.
51
Interest Penalty Charge
This is the interest assessment for late filing.
72
Authorized Return
This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. PLB03-2 must always contain an identifying reference number when the value is used. PLB04 must contain a negative value. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
90
Early Payment Allowance
AH
Origination Fee
This is the claim transmission fee. This is used for transmission fees that are not specific to or dependent upon individual claims.
AM
Applied to Borrower's Account
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. Use this code to identify the loan repayment amount.

This is capitation specific.
AP
Acceleration of Benefits
This is the accelerated payment amount or withholding. Withholding or payment identification is indicated by the sign of the amount in PLB04. A positive value represents a withholding. A negative value represents a payment.
B2
Rebate
This adjustment code applies when a provider has remitted an overpayment to a health plan in excess of the amount requested by the health plan. The amount accepted by the health plan is reported using code 72 (Authorized Return) and offset by the amount with code WO (Overpayment Recovery). The excess returned by the provider is reported as a negative amount using code B2, returning the excess funds to the provider.
B3
Recovery Allowance
This represents the check received from the provider for overpayments generated by payments from other payers. This code differs from the provider refund adjustment identified with code 72. This adjustment must always be offset by some other PLB adjustment referring to the original refund request or reason. For balancing purposes, the amount related to this adjustment reason code must be directly offset.
BD
Bad Debt Adjustment
This is the bad debt passthrough.
BN
Bonus
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
C5
Temporary Allowance
This is the tentative adjustment.
CR
Capitation Interest
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CS
Adjustment
Provide supporting identification information in PLB03-2.
CT
Capitation Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
CV
Capital Passthru
CW
Certified Registered Nurse Anesthetist Passthru
DM
Direct Medical Education Passthru
E3
Withholding
See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
FB
Forwarding Balance
This is the balance forward. A negative value in PLB04 represents a balance moving forward to a future payment advice. A positive value represents a balance being applied from a previous payment advice. A reference number must be supplied in PLB03-2 for tracking purposes. See 1.10.2.12, Balance Forward Processing, for further information.
FC
Fund Allocation
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information. The specific fund must be identified in PLB03-2.
GO
Graduate Medical Education Passthru
HM
Hemophilia Clotting Factor Supplement
IP
Incentive Premium Payment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
IR
Internal Revenue Service Withholding
IS
Interim Settlement
This is the interim rate lump sum adjustment.
J1
Nonreimbursable
This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
L3
Penalty
This is the capitation-related penalty. Withholding or release is identified by the sign in PLB04. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
L6
Interest Owed
This is the interest paid on claims in this 835. Support the amounts related to this adjustment by 2-062 AMT amounts, where AMT01 is "I".
LE
Levy
IRS Levy
LS
Lump Sum
This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The specific type of lump sum adjustment must be identified in PLB03-2.
OA
Organ Acquisition Passthru
OB
Offset for Affiliated Providers
Identification of the affiliated providers must be made on PLB03-2.
PI
Periodic Interim Payment
This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For instance, when a provider has a PIP payment, claims within this remittance advice covered by that payment would be offset using this code to remove the claim payment from the current check. The sign of the amount in PLB04 determines whether this is a payment (negative) or reduction (positive).

This payment and recoupment is effectively a loan to the provider and loan repayment.

See section 1.10.2.5, Advance Payments and Reconciliation, for additional information.
PL
Payment Final
This is the final settlement.
RA
Retro-activity Adjustment
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
RE
Return on Equity
SL
Student Loan Repayment
TL
Third Party Liability
This is capitation specific. See 1.10.2.10, Capitation and Related Payments or Adjustments, for additional information.
WO
Overpayment Recovery
This is the recovery of previous overpayment. An identifying number must be provided in PLB03-2. See the notes on codes 72 and B3 for additional information about balancing against a provider refund.
WU
Unspecified Recovery
Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
Situational
13-2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SITUATIONAL RULE: Required when a control, account or tracking number applies to this adjustment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Identifier
Situational
14
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: PLB14 is the adjustment amount.
SEGMENT SYNTAX: P1314
SITUATIONAL RULE: Required when PLB13 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Adjustment Amount
This is the adjustment amount for the preceding adjustment reason.

SE - TRANSACTION SET TRAILER

X12 Name:
Transaction Set Trailer
X12 Purpose:
To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
X12 Comments:
SE is the last segment of each transaction set.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
SE✱45✱1234~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
96
Number of Included Segments
M 1
N
1/10
Total number of segments included in a transaction set including ST and SE segments
INDUSTRY NAME: Transaction Segment Count
Required
2
329
Transaction Set Control Number
M 1
AN
4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
The Transaction Set Control Numbers in ST02 and SE02 must be identical. The originator assigns the Transaction Set Control Number, which must be unique within a functional group (GS-GE). This unique number also aids in error resolution research.

GE - FUNCTIONAL GROUP TRAILER

X12 Name:
Functional Group Trailer
X12 Purpose:
To indicate the end of a functional group and to provide control information
X12 Comments:
The use of identical data interchange control numbers in the associated functional group header and trailer is designed to maximize functional group integrity. The control number is the same as that used in the corresponding header.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
GE✱1✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
97
Number of Transaction Sets Included
M 1
N
1/6
Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element
Required
2
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06.

IEA - INTERCHANGE CONTROL TRAILER

X12 Name:
Interchange Control Trailer
X12 Purpose:
To define the end of an interchange of zero or more functional groups and interchange-related control segments
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
IEA✱1✱000000905~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I16
Number of Included Functional Groups
M 1
N
1/5
A count of the number of functional groups included in an interchange
Required
2
I12
Interchange Control Number
M 1
N
9
A control number assigned by the interchange sender

835 Health Care Claim Payment/Advice (005010X221, 005010X221E1, 005010X221A1)

Chapter 1. Purpose and Business Information

1.1 Implementation Purpose and Scope

For the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical.

The purpose of this implementation guide is to provide standardized data requirements and content for all users of ANSI ASC X12.835, Health Care Claim Payment/ Advice (835). This implementation guide provides a detailed explanation of the transaction set by defining data content, identifying valid code tables, and specifying values that are applicable for electronic claims payment. The intention of the developers of the 835 is represented in this guide.

This implementation guide is designed to assist those who send and/or receive Electronic Remittance Advice (ERA) and/or payments in the 835 format.

Entities receiving the 835 include, but are not limited to, hospitals, nursing homes, laboratories, physicians, dentists, and allied professional groups. All of these entities are referred to as payees or providers within this document.

Organizations sending the 835 include insurance companies, Third Party Administrators (TPAs), service corporations, state and federal agencies and their contractors, plan purchasers, and any other entities that process health care reimbursements. Other business partners affiliated with the 835 include Depository Financial Institutions (DFIs), billing services, consulting services, vendors of systems, software and EDI translators, EDI network intermediaries such as Automated Clearing Houses, value-added networks, and telecommunication services.

All of these entities are referred to as payers or health plans within this document.

1.2 Version Information

This implementation guide is based on the October 2003 ASC X12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010).

The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 005010X221A1.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

  • HP Health Care Claim Payment/Advice (835)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C, EDI Control Directory.

1.3 Implementation Limitations

1.3.1 Batch and Real-time Usage

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (suchas a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction. This implementation guide does not set specific response time parameters for these activities.

Real Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide is intended to support use in batch mode. This implementation guide is not intended to support use in real-time mode. A statement that the transaction is not intended to support a specific mode does not preclude its use in that mode between willing trading partners.

1.3.2 Other Usage Limitations

There is no recommended limit to the number of ST-SE transactions within a GS-GE or ISA-IEA. When payment is via an electronic funds transfer and the remittance information is moved through the banking system, size limitations due to restrictions within the banking network may limit the size of the 835 transaction.

1.4 Business Usage

The 835 is intended to meet the particular needs of the health care industry for the payment of claims and transfer of remittance information. The 835 can be used to make a payment, send an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice from a payer to a payee, either directly or through a DFI.

In all instances, "payee" refers to the actual providers and/or their agents. Likewise, "payer" refers not only to the actual payer but to any third party agent as well.

1.4.1 Information Flows

Figure 1.1 - Information Flow, illustrates the flow of information from payer to payee directly or through their DFIs.

Figure 1.1 - Information Flow

Information Flow

1.5 Business Terminology

The following business terms are used in this implementation guide.

Adjustment

Within the scope of this guide and the 835, the term adjustment refers to changes to the amount paid on a claim, service or remittance advice versus the original submitted charge/bill. Adjustment does not refer to changing or correcting a previous adjudication of a claim.

DFI - Depository Financial Institution

EFT - Electronic Funds Transfer

ERA - Electronic Remittance Advice

FDN - Funds Deposit Notification

Funds - Actual dollars, check or other

Payee - Actual providers and/or their agents

Payer - Actual payer and any third party agent

CARC - Claim adjustment Reason Code

1.6 Transaction Acknowledgments

There are several acknowledgment implementation transactions available for use. The IG developers have noted acknowledgment requirements in this section. Other recommendations of acknowledgment transactions may be used at the discretion of the trading partners. A statement that the acknowledgment is not required does not preclude its use between willing trading partners.

1.6.1 997 Functional Acknowledgment

The 997 informs the submitter that the functional group arrived at the destination. It mayinclude information about the syntactical quality of the functional group.

The Functional Acknowledgment (997) transaction is not required as a response to receiptof a batch transaction compliant with this implementation guide.

The Functional Acknowledgment (997) transaction is not required as a response to receiptof a real-time transaction compliant with this implementation guide.

A 997 Implementation Guide is being developed for use by the insurance industry and isexpected to be available for use with this version of this Implementation Guide.

1.6.2 999 Implementation Acknowledgment

The 999 informs the submitter that the functional group arrived at the destination. It mayinclude information about the syntactical quality of the functional group and theimplementation guide compliance.

The Implementation Acknowledgment (999) transaction is not required as a response toreceipt of a batch transaction compliant with this implementation guide.

The Implementation Acknowledgment (999) transaction is not required as a response toreceipt of a real-time transaction compliant with this implementation guide.

A 999 Implementation Guide is being developed for use by the insurance industry and isexpected to be available for use with this version of this Implementation Guide.

1.6.3 824 Application Advice

The 824 informs the submitter of the results of the receiving application system's datacontent edits of transaction sets.

The Application Advice (824) transaction is not required as a response to receipt of abatch transaction compliant with this implementation guide.

The Application Advice (824) transaction is not required as a response to receipt of areal-time transaction compliant with this implementation guide.

An 824 Implementation Guide is being developed for use by the insurance industry and isexpected to be available for use with this version of this Implementation Guide.

1.7 Related Transactions

There are transactions related to the transactions described in this implementation guide.

1.7.1 Data Relationship with Other Transactions (837, 277, NCPDP)

A one-for-one relationship does not exist among the Health Care Claim Transaction Set (837), the Health Care Claim Status Notification Transaction Set (277), and the 835. One 835 transaction set can account for claims submitted using multiple 837 transactions. The Claim Submitter's Identifier reported in the claim within the 837 is returned in the 835 transaction for tracking purposes. The Claim Submitter's Identifier is located in the 837 in CLM01. In the 835, the Claim Submitter's Identifier, for example, a patient control number, is in CLP01. For Pharmacy the Claim Submitter's Identifier is located in the NCPDP Claim Segment , Prescription Service Reference Number (402-D2).

The 277's primary use is to convey status information on non-adjudicated claims; the 835 is used to transmit data needed for posting subsequent to the adjudication of a claim. The 277 also can account for claims already paid by an 835. In this case, a one-for-one relationship does not exist between the transactions.

The Claim Submitter's Identifier, reported in the claim within the 837 always is returned in the 835 and frequently is returned in the 277 transaction for tracking purposes. When used in the 277, the Claim Submitter's Identifier is located in TRN02.

There is also a Prescription Drug Claim Transaction created by the National Council for Prescription Drug Programs (NCPDP). Similar to the 837 transaction, a one-for-one relationship does not exist between the NCPDP claim format and the 835. One 835 transaction can account for claims submitted using multiple NCPDP transactions. The Claim Submitter's identifier is located in the NCPDP claim segment, Prescription/Service Reference Number (402-D2).

1.8 Trading Partner Agreements

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

1.9 HIPAA Role in Implementation Guides

Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary of Health and Human Services to adopt standards for transactions to enable health information to be exchanged electronically and to adopt specifications for implementing each standard.

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a HIPAA standard. Should the Secretary adopt this implementation guide as a standard, the Secretary will establish compliance dates for its use by HIPAA covered entities.

1.10 Data Overview

1.10.1 Overall Data Architecture

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

1.10.1.1 Payment

The 835 contains information about the payee, the payer, the amount, and any identifying information of the payment. In addition, the 835 can authorize a payee to have a DFI take funds from the payer's account and transfer those funds to the payee's account.

The 835 can authorize a DFI to move funds. In this mode, the 835 is sent to the payer's DFI. The 835 includes information about the payer's account; the payee's DFI, account, and timing; and the method and amount of the funds transfer. This process is known as an "Electronic Funds Transfer" (EFT). The result of an EFT is that funds are deposited directly into the payee's account. The remittance information may or may not have been transmitted to and through the banking network.

One 835 transaction set reflects a single payment device. In other words, one 835 corresponds to one check or one EFT payment. Multiple claims can be referenced within one 835.

1.10.1.2 Flows (Dollars and Data)

With the various capabilities inherent in the 835, many ways exist to combine the Electronic Remittance Advice (ERA) and the actual payment ($). Figure 1.2 - ERA with Payment by Check through Figure 1.6 - ERA with Debit EFT illustrate several methods.

1.10.1.2.1 ERA with Payment by Check

Figure 1.2 - ERA with Payment by Check

ERA with Payment by Check
1.10.1.2.2 ERA and EFT through DFI

Figure 1.3 - ERA and EFT through DFI

ERA and EFT through DFI
1.10.1.2.3 ERA with Payment by Separate EFT

Figure 1.4 - ERA with Payment by Separate EFT

ERA with Payment by Separate EFT
1.10.1.2.4 ERA and Payment Delivered Separately but Processed by a Value-Added Bank (VAB)

Figure 1.5 - ERA and Payment Separate, Processed by VAB

ERA and Payment Separate, Processed by VAB
1.10.1.2.5 ERA with Debit EFT

Figure 1.6 - ERA with Debit EFT

ERA with Debit EFT

1.10.1.3 Electronic Funds Transfer

Electronic Funds Transfer (EFT) is the electronic mechanism that payers use to instruct one DFI to move money from one account to another account at the same or at another DFI. The information required for the funds transfer is communicated electronically. Many formats are available for the actual data in the electronic message, and different formats apply at each stage. The formats can be proprietary to a particular institution, standard Automated Clearing House (ACH) formats, or ASC X12 transaction sets (820 or 835). See Table 1.1 - Data Formats, for the data formats that apply at each stage.

Table 1.1 - Data Formats

Stage (credit transaction)ProprietaryACHASC X12
Payer to Payer's DFIYesYesYes
Payer's DFI to Payee's DFINoYes (note)No
Payee's DFI to PayeeYesYesYes
Stage (debit transaction)
Payee to Payee's DFIYesYesYes
Payee's DFI to Payer's DFINoYes (note)No
Payer's DFI to PayerYesYesYes
NOTE: An 835 moves from one DFI to another DFI encapsulated within an ACH transaction when the DFIs use the ACH network.

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

Specific EFT formats can carry varying degrees of remittance information through the banking industry's ACH. When the remittance information accompanying the EFT goes through the ACH, the payee receives direct information about the reason for the payment. When the remittance information is not conveyed with the dollar information, a way to reassociate the dollars and the remittance data is needed. A unique number related to the specific funds transfer is used for identification when the 835 is used as the remittance carrier. This unique number is the trace number contained in the 835 in the Reassociation Key Segment, TRN. The trace number must be conveyed in the EFT request, and eventually the number is delivered to the payee with notification of the payment. When sending the TRN in an 835 with the EFT, the Cash Concentration/Disbursement plus Addenda (CCD+) ACH format is specified in the Financial Segment, BPR, using the code value CCP in BPR05. Then the TRN is transferred within the CCD+ as an addenda record and passed to the payee. It is prudent for any payer to contact their DFI to work out details for initiating an EFT. For federal agencies paying through the Department of the Treasury, the Department of the Treasury is their DFI.

1.10.1.4 Remittance

As a remittance advice, the 835 provides detailed payment information relative to the health care claim(s) and, if applicable, describes why the total original charges have not been paid in full. This remittance information is provided as documentation for the payment, as well as input to the payee's patient accounting system/accounts receivable (A/R) and general ledger applications. The remittance information consists of two separate levels. See Figure 1.7 - Remittance Information Levels. Level one consists of claim and service information "packaged" within the Detail Loop, Table 2. The loop may occur multiple times to provide a logical grouping of the claim and service information.

Figure 1.7 - Remittance Information Levels

Remittance Information Levels

Level two consists of remittance information that is not specific to the claim(s) and service(s) contained in level one. This remittance information is contained in the Provider Level Adjustment Segment, PLB. The PLB segment provides for reporting increases or reductions to the amount remitted in conjunction with reference numbers for further identification.

When the 835 does not contain remittance information, Table 2 and the PLB are omitted.

The 835 must be balanced whenever remittance information is included in an 835 transaction. For a balanced 835, the total payment must agree with the remittance information detailing that payment. The remittance information must also reflect an internal numeric consistency. See Section 1.10.2.1 - Balancing, for complete details.

1.10.2 Data Use by Business Use

This section and all subsections identify the business structure of the 835 and specific solutions or usage that relate to health care claim payment and remittance business issues. These solutions may not be the only possible solutions within an ASC X12 835 transaction. They are, however, the only solutions for the business situations identified that are compliant with this implementation guide. Creation of 835 transactions that are not consistent with the information here is prohibited under this implementation.

The three levels are:

  • The Header level, Table 1, contains general payment information, such as amount, payee, payer, trace number, and payment method.

  • The Detail level, Table 2, contains the EOB information related to adjudicated claims and services.

  • The Summary level, Table 3, contains the Provider adjustment segment, PLB which provides information related to adjustments to the payment amount not specific to Table 2 claims. These adjustments can either increase or decrease the actual payment with respect to the Table 2 claim charges.

Figure 1.8 - 835 Transaction Set Listing

835 Transaction Set Listing

Although the remittance information in Tables 2 and 3 are not always provided, the intention of this business use of the 835 is for payers to provide some claim or provider-specific information along with the payment information.

When dollars and data are delivered separately, an 835 with no Table 2 or PLB segment in Table 3 can initiate a financial transaction.

NOTE

The 835 is used to transmit payment and data needed for the posting by a provider subsequent to the adjudication of a claim. Non-adjudicated claim information should be carried in the ASC X12 Health Care Claim Status Notification Transaction Set (277).

1.10.2.1 Balancing

The amounts reported in the 835, if present, MUST balance at three different levels -- the service line, the claim, and the transaction. Adjustments within the 835, through use of the Claim Adjustment and Service Adjustment Segments, CAS, or Provider Level Adjustment Segments, PLB, DECREASE the payment when the adjustment amount is POSITIVE, and INCREASE the payment when the adjustment amount is NEGATIVE. See Section 1.10.2.4 - Claim Adjustment and Service Adjustment Segment Theory, for more details.

NOTE

Amounts are not present and balancing does not apply when an 835 is used ONLY to initiate an electronic funds transfer as described in Section 1.10.1.3 - Electronic Funds Transfer with the CCD+ ACH format. In this case, Table 2 and the PLB segment in Table 3 are not present.

1.10.2.1.1 Service Line Balancing

Figure 1.9 - Service Line Balancing Segments

Service Line Balancing Segments

Although the service payment information is optional, it is REQUIRED for all professional claims or anytime payment adjustments are related to specific line items from the original submitted claim. When used, the submitted service charge plus or minus the sum of all monetary adjustments must equal the amount paid for this service line.

Amount 1 - Amount 2 = Amount 3

where:

Amount 1 -- transmitted in the Service Payment Information Segment, SVC02 -- is the submitted charge for this service line.

Amount 2 -- transmitted in the Service Adjustment Segment, the sum of CAS03, 06, 09, 12, 15, and 18 -- is the monetary adjustment amount applied to this service line.

Amount 3 -- transmitted in the Service Payment Information Segment, SVC03 -- is the paid amount for this service line.

NOTES

  • Adjustments within CAS DECREASE the payment when the adjustment amount is POSITIVE, and INCREASE the payment when the adjustment amount is NEGATIVE.

  • Providing service detail is critical for business, especially when professional or fee-based services are involved.

All services for the claim being paid from the adjudication system must be reported. This may be a subset of the original claim services when claims are split. See Section 1.10.2.11 - Claim Splitting, for the requirements when splitting claims.

  • If any service detail is reported in the claim payment, all services for the claim payment must be reported.

See Section 1.10.2.19 - Reporting Encounters in the 835 for additional information and for the service line reporting exception for encounter services.

1.10.2.1.2 Claim Balancing

Figure 1.10 - Claim Balancing Segments

Claim Balancing Segments

Balancing must occur within each Claim Payment loop so that the submitted charges for the claim minus the sum of all monetary adjustments equals the claim paid amount.

When the Service Payment Information loop is not present, the following formula applies:

Amount 4 - Amount 5 = Amount 6

where,

Amount 4 -- transmitted in the Claim Payment Segment, CLP03 -- is the total submitted charge for the claim.

Amount 5 -- transmitted in the Claim Adjustment Segment, the sum of CAS03, 06, 09, 12, 15, and 18 -- is the monetary adjustment amount applied to this claim.

Amount 6 -- transmitted in the Claim Payment Segment, CLP04 -- is the paid amount for this claim.

When the Service Payment Information loop is present, the following formula applies:

Amount 7 - Amount 8 = Amount 9

where,

Amount 7 -- transmitted in the Claim Payment Segment, CLP03 -- is the total submitted charge for the claim.

Amount 8 -- transmitted in the Claim Adjustment Segment and/or Service Adjustment Segment, the sum of CAS03, 06, 09, 12, 15, and 18 -- is the monetary adjustment amount applied to this claim.

Amount 9 -- transmitted in the Claim Payment Segment, CLP04 -- is the paid amount for this claim.

NOTES

Adjustments within the Claim Adjustment or Service Adjustment Segments DECREASE the payment when the adjustment amount is POSITIVE and INCREASE the payment when the adjustment amount is NEGATIVE.

When balancing claims that include the Service Payment Information loop, all Claim Adjustment and Service Adjustment monetary amounts are included in the balancing equation (amount 8 above). When balancing claims that do not include the Service payment Information loop, all Claim Adjustment monetary amounts are included in the balancing equation (Amount 5 above).

When the Service Payment Information loop is present, adjustments are reported in either the Claim Adjustment or the Service Adjustment Segments but not in both. For example, if a $100 deductible adjustment is taken at the service level, do not repeat that deductible at the claim level. It is preferred that the adjustment be shown at the service level when possible.

When specific service detail is presented, the claim level balancing includes balancing the total claim charge (CLP03) to the sum of the related service charges (SVC02). Service lines that are not finalized must be adjusted with a CAS segment using a Claim Adjustment Group code (CAS01) of 'OA' (Other Adjustment), a Claim Adjustment Reason code (CAS02) of 133 (This service is suspended pending further review) and the full dollar amount for the service in CAS03. When finalized, the claim must be reported using the instructions found in the Reversal and Correction section. See Section 1.10.2.11 - Claim Splitting, for variations related to claim splitting situations.

1.10.2.1.3 Transaction Balancing

Figure 1.11 - Transaction Balancing Segments

Transaction Balancing Segments

Within the transaction, the sum of all claim payments minus the sum of all provider level adjustments equals the total payment amount.

Amount 10 - Amount 11 = Amount 12

where:

Amount 10 -- the sum of all CLP04 amounts transmitted in the Claim Payment Segment -- is the total of all claim amounts included in this transaction set.

Amount 11 -- the sum of PLB04, 06, 08, 10, 12, and 14 transmitted in the Provider Adjustments Segment -- is the provider level adjustment made to the claim payment.

Amount 12 -- transmitted in the Financial Information Segment, BPR02 -- is the total payment amount of this claim payment.

NOTE

A POSITIVE amount in PLB indicates a DECREASE in the payment amount. A NEGATIVE amount in PLB indicates an INCREASE in the payment amount.

1.10.2.2 Remittance Tracking

Figure 1.12 - Remittance Tracking Segments

Remittance Tracking Segments

The Reassociation Key Segment, TRN, contains a trace number for the transaction set. Trace Number, TRN02, which is used to reassociate payments and remittances sent separately, must be a unique number for this business purpose between the payer and the payee. This will be:

  • For check payments, TRN02 is the check number.

  • For EFT payments, TRN02 is the unique number assigned by the payer to identify this EFT.

  • For non-payment transactions, TRN02 is a unique number generated by the transaction set originator as that 835's identification number (e.g., a control number plus a suffix or a date/time stamp).

In addition, TRN03 is the payer's identification number. TRN03 allows the payee to avoid matching problems in case multiple payers use the same number in TRN02.

NOTE

Due to the need for remittance tracking, there is a one to one relationship between any specific 835 and the related payment mechanism (check or EFT). One 835 must only relate to a single payment mechanism and one payment mechanism must only relate to a single 835. The only exception is a non-payment 835 (BPR02=0) where there is no associated payment mechanism.

1.10.2.3 Reassociation of Dollars and Data

The 835 is capable of sending health care claim payment remittance data with or without the dollars represented by the data. It is important to facilitate reassociation when the remittance data is sent separately from the monetary amounts. Reassociation requires that both remittance and monetary data contain information that allows a system to match the items received. The provider should have a method to ensure that payment and remittance advice are reconciled in the patient accounting/accounts receivable system.

Two key pieces of information facilitate reassociation -- the trace number in the Reassociation Key Segment, TRN02, and the Company ID Number, TRN03. The trace number in conjunction with the company ID number provides a unique number that identifies the transaction.

The two ways of sending payment for health care remittance data are check or ACH. In the case of a payment received by check, the check number is the trace number in TRN02, and the company ID number is in TRN03. When the check is processed, the check number and account information are captured. A table may be necessary to cross reference the account information from the check to the company ID number received in TRN03. This information should be gathered when the transaction is implemented with the payer.

When sending a separate ACH payment, the CCD+ ACH format is used. Using this method, the Re-association Key Segment in its entirety is contained in the ACH Addenda Record.

For complete details on reassociation and ACH file formats, contact either your local Value Added Bank (VAB) or the National Automated Clearing House Association at (703) 561-1100.

1.10.2.3.1 Lost and Reissued Payments

Occasionally, the reassociation process identifies a received remittance advice without the associated payment. This could result from situations like a lost check or misdirected EFT (incorrect payee bank information).

Since there is no problem with the remittance information, there is no need to recreate or retransmit that information. In fact, since some payees may have proceeded to post the original remittance information to their A/R, replacing that information could cause problems to the payee's system. The lost payment is replaced using one of two methods.

The first method is an administrative check or EFT. When the replacement is a check, information identifying the original payment is supplied on the stub. This includes at least the Trace Number (TRN02) from the remittance advice, which corresponds to the check or EFT number being replaced. When the replacement is an EFT, the CCD+ ACH format must be used and the original Reassociation Key Segment (TRN) is again placed in the addenda record.

The second option for the payer is to include the lost payment within the PLB segment of a subsequent 835. When using this method, one of the PLB segment adjustment pairs is used to add the lost funds to the new payment. The first element of the associated Adjustment Identifier contains code CS (Adjustment) with the second element identifying the TRN02 value from the original 835. The dollar amount of the original payment (BPR02) is placed in the amount element of the adjustment pair using a negative sign. There is no repeat of the claim level detail from the original 835.

The payer follows any normal procedures to stop payment on the lost check or to reverse the incorrect EFT.

1.10.2.4 Claim Adjustment and Service Adjustment Segment Theory

The Claim Adjustment and Service Adjustment Segments provide the reasons, amounts, and quantities of any adjustments that the payer made either to the original submitted charge or to the units related to the claim or service(s). The summation of the adjustments at the claim and service levels is the total adjustment for the entire claim. Service level adjustments are not repeated at the claim level.

Figure 1.13 - Claim and Service Adjustment Segments

Claim and Service Adjustment Segments

A standardized list of claim adjustment reason codes is used in the Claim Adjustment and Service Adjustment Segments. See Appendix A, External Code Sources, for the List location. These codes provide the "explanation" for the positive or negative financial adjustments specific to particular claims or services that are referenced in the transmitted 835. Other financial adjustments can be expressed in the PLB segment; however, the claim adjustment reason code list is not used for provider level adjustments.

To facilitate and expedite reason code maintenance, the list was established external to the ASC X12 standards. The Blue Cross Blue Shield Association created a committee of payer and provider representatives to maintain the list. As with any external code list, maintenance requests should be addressed to the responsible entity. Send maintenance requests in writing to the Blue Cross Blue Shield Association or submit online via www.wpc-edi.com (preferred).

The Claim Adjustment Group Code, CAS01, categorizes the adjustment reason codes that are contained in a particular CAS. The Claim Adjustment Group Codes are evaluated according to the following order:

  1. Is the amount adjusted in this segment the patient's responsibility?

    Use code PR - Patient Responsibility.

  2. Is the amount adjusted not the patient's responsibility under any circumstances due to either a contractual obligation between the provider and the payer or a regulatory requirement?

    Use code CO - Contractual Obligation.

    An example of a contractual obligation might be a Participating Provider Agreement.

  3. In the payer's opinion, is the amount in this segment not the responsibility of the patient, without a supporting contract between the provider and the payer?

    Use code PI - Payer Initiated.

  4. If no other category is appropriate, do the following:

    Use code OA - Other Adjustment.

Avoid using the Other Adjustment Group Code (OA) except for business situations described in sections 1.10.2.6, 1.10.2.7 and 1.10.2.13.

Only use the Claim Adjustment Segment if needed.

At either position -- the claim level or the service level -- each CAS can report up to six different adjustments related to a particular Claim Adjustment Group. This can be seen by noting the re-occurrence of the Claim Adjustment Reason, Monetary Amount, and Quantity data elements, referred to as "an adjustment trio," in the CAS. There is no direct correlation between any particular kind of adjustment and a specific adjustment data element trio. For example, a co-insurance adjustment does not belong at any specific position in the segment. The assumption is that no adjustment trio is used if no meaningful data is included. For efficiency, the first significant adjustment is placed at the first trio -- CAS02, 03, and 04. The six iterations (trios) of the Adjustment Reason Code related to the Specific Adjustment Group Code must be exhausted before repeating a second iteration of the CAS segment using the same Adjustment Group Code.

For example:

CAS*CO*5*793**131*25**96*1**110*3**115*5**15*42~
CAS*CO*119*250~

(Note: this example is only for the purpose of demonstrating the correct usage of CAS Group Codes and Adjustment Reason Codes in completing the 6 trios per CAS segment. The relationship of the Group Code and Adjustment Reason Codes as provided in the example are not intended to suggest what relationship may exist for your business

Adjustments do not get reported in an 835 in any specific order. The order for determining the applicable group is not intended to require reporting the groups in that order.

1.10.2.4.1 Institutional-Specific Use

Within the institutional environment, certain circumstances require special handling. Although it is customary in the non-institutional and outpatient environment to provide adjustments and full service line detail with the remittance advice, this situation is unusual for inpatient claims. There are circumstances when there is a need to provide service-specific adjustments, but it is not desirable to provide all service information. When working with room rate adjustments, administrative days, or non-covered days, it may be appropriate to provide these adjustments at the claim level and not provide service level detail. Claim Adjustment Reason Code 78, Non-covered Days/Room Charge Adjustment, is used in the claim level CAS segment to report an adjustment in the room rate or in the number of days covered. The associated adjustment amount provides the total dollar adjustment related to reductions in the number of covered days and the per day rate. The associated adjustment quantity is used to report the actual number of non-covered days.

1.10.2.5 Advance Payments and Reconciliation

In some instances, the relationship between the payer and the provider involves periodic advance payments against expected claim volume and subsequent adjustments against the advance as the actual claims are processed. These advance payments can cover all claims, certain types of claims or a percentage of certain claims.

The advance payments and adjustments are made using an Adjustment Identifier composite and Monetary Amount element pair in the PLB segment (PLB 03/04, 05/06, 07/08, 09/10, 11/12 or 13/14).

The Adjustment Identifier consists of an Adjustment Reason Code and a Reference Identification element. For advance payments and subsequent adjustments (money taken back) the Adjustment Reason Code will be PI (Periodic Interim Payment). The Reference Identification must be used to identify the Payer assigned financial control number for the payment. This same control number must be supplied on all adjustments related to a payment to facilitate reconciliation by the provider.

The Monetary Amount element identifies the dollars involved and whether it is a payment or adjustment. A negative dollar amount indicates a payment, and increases the payment to the provider in the 835. A positive dollar amount indicates an adjustment and a reduction in the payment in the 835.

The 835 does not provide any association between any specific claim and the advance payment process in the PLB. The provider and payer should clearly establish the business details (claim/service types applicable) external to the 835.

NOTE

The advance payment adjustment is not specific to a particular claim and is not reducing the amount paid on the claim. It is an administrative adjustment related to the original advance payment. As a result, it is reported in the PLB segment and not in the CAS segment.

Example:

Medicaid State General Fund (SGF) and Federal Financial Participation (FFP) will be the multiple sources of funding and payment of certain claims.

If an applicable Medicaid claim is submitted for $100 it is paid out of two funds with $50 SGF and $50 FFP. The SGF portion may be paid on a 1/12 allotment of the year's estimate. e.g. If the provider will send in approximately $240,000 of claims, then $120,000 will be paid in $10,000 increments each month.

The monthly 1/12th payments get reported and paid in the 835 as a PLB adjustment, using the adjustment reason code of PI with a reference number for the period:

PLB*12345*20031231*PI:SGF87654*-10000~

When a claim is submitted, the claim paid amount (CLP04) will be $100. The FFP amount is paid by Medicaid and is part of the BPR02 payment amount for the 835. The SGF portion of the payment is credited against the estimated yearly amount that is being paid monthly and is recouped in the PLB segment. The total process will be reconciled at the end of the year in a cost report activity. Only the CLP and PLB segments are shown for simplicity.

CLP*A231623*1*100*100**MC*9878768~
PLB*12345*20031231*PI:SGF87654*50~

If there were 10 claims instead of 1 in the advance payment process for this remittance, the PLB would read:

PLB*12345*20031231*PI:SGF87654*500~

NOTE

Once the advanced payment has been completely recouped, the PLB adjustments cease until after the next advance payment. The payer and provider can establish the periodicity of the advance payment reconciliation process. For instance, with the example scenario above:

  1. Use unique monthly advance payment reference identifications. Once you reach $10,000 in $50 adjustments for a given month, stop taking additional adjustments and start paying the full $100 for each additional claim that month -- or

  2. Use one reference number for all of the payments in the year and always take the $50 adjustment on each claim. Reconcile at the end of the entire year (or start paying $100 once the yearly allotment has been exceeded).

1.10.2.6 Procedure Code Bundling and Unbundling

Procedure code bundling or unbundling occurs when a payer believes that the actual services performed and reported for a claim payment can be represented by a different group of procedure codes. Grouping usually results in a lower payment from the payer. Bundling occurs when two or more reported procedures are going to be paid under only one procedure code. Unbundling occurs when one submitted procedure code is to be paid and reported back as two or more different procedure codes. This results in an increase in the units of service for the claim.

Splitting of a service line with multiple units of service into multiple service lines and maintaining the same total units of service is not unbundling. See Section 1.10.2.14.1 - Service Line Splitting, for additional information.

When bundling or unbundling occurs, the information must be reported back to the payee accurately to facilitate automatic entry into a patient accounting/accounts receivable system. In the interest of standardization, payers are to report bundling or unbundling in a consistent manner.

When bundling, report all of the originally submitted procedures in the remittance advice. Report all procedures as paying on the changed (bundled) procedure code, and reference the original submitted code in SVC06. The bundled service line must be adjusted up by an amount equal to the sum of the other line charges. This is reported as a CAS segment with a group code OA (Other Adjustments) and a reason code of 94 (Processed in Excess of Charges) with a negative dollar amount. From that point, apply all normal CAS adjustments to derive the reimbursement amount. Report the other procedure or procedures as originally submitted, with an adjudicated code of the bundled procedure code and a Claim Adjustment Reason Code of 97 (payment is included in the allowance for the basic service) and an adjustment amount equal to the submitted charge. The Adjustment Group is either CO (Contractual Obligation) or PI (Payer Initiated) depending on the provider/payer relationship.

NOTE

The following examples illustrate bundling and unbundling within a PPO environment. Some segment use may vary from payer type to payer type.

Bundling Example

This is an example of a Preferred Provider Organization (PPO) claim. This example leaves out the date and other segments not necessary to bundling.

  • The provider submits procedure code "A" and "B" for $100.00 each to his or her PPO as primary coverage. The procedures were performed on the same date of service.

  • The PPO's adjudication system screens the submitted procedures and notes that procedure "C" covers the services rendered by the provider on that single date of service.

  • The PPO's maximum allowed amount for procedure "C" is $120.00.

  • The patient's co-insurance amount for procedure "C" is $20.00.

  • The patient has not met the $50.00 deductible.

CLP*123456789*1*200*50*70*12~
CAS*PR*1*50~
SVC*HC:C*100*100***HC:A~
CAS*OA*94*-100~
CAS*CO*45*80~
CAS*PR*2*20~
SVC*HC:C*100*0**0*HC:B*1~
CAS*CO*97*100~

When unbundling, report the original service as the first of the new services with the original submitted charge in SVC02. Use subsequent SVC loops for the other new services. For these other services, report the submitted charge as zero dollars ($0.00). As in bundling, CAS is used to increase the submitted charge from $0.00 to the allowed amount for each procedure. Report the original procedure code in all of the SVC loops in SVC06. Balancing must be maintained for all service lines.

Unbundling Example

  • The same PPO provider submits a claim for one service.

  • The service code is "A" with a claim submitted charge and service charge of $200.00.

  • The payer unbundles this into 2 services -- "B" and "C" -- each with an allowed amount of $60.00.

  • There is no deductible or co-insurance amount.

Only segments specific to unbundling are included in the example. Adjustment reason code 45, "charges exceed your contracted/legislated fee arrangement," is used for each service.

CLP*123456789*1*200*120*0*12~
SVC*HC:B*200*60***HC:A~
CAS*CO*45*140~
SVC*HC:C*0*60***HC:A~
CAS*OA*94*-60~

Partial Unbundling

Partial unbundling may occur when a bundled panel of services, such as a lab panel or a surgical panel, is billed under a single HCPCS assigned to that panel, and a denial or reduction is made related to only one or some of the services in that panel. For example, two lab panels may include the same lab test. The full amount would be payable for the first panel, but a lesser amount may be due for the second panel due to the overlap.

Rather than totally unbundle the panels to be able to report detail on individual services within the panel, it is possible to do a partial unbundling to highlight only the individual service being adjusted. If this is done, however, you must report the regular allowed and payable amounts for the panel, then use a negative payment with the single adjusted service to offset for that reduction and to link that individual service to the HCPCS for the affected panel. The allowed amount for the single unbundled adjusted service in the panel must be reported as 0 when there is partial unbundling. This results in an increase in the units of service for the claim.

Splitting of a service line with multiple units of service into multiple service lines and maintaining the same total units of service is not unbundling. See Section 1.10.2.14.1 - Service Line Splitting, for additional information.

Partial Unbundling Example (Two lab panels billed and one test repeated in each):

CLP*123456789*1*72*66*0*12~
SVC*HC:80049*42*42~
SVC*HC:80054*30*30~
SVC*HC:82435*0*-6**0*HC:80054*1~
CAS*CO*18*1~

NOTE

When following Unbundling or Partial Unbundling procedures, payers are required to return all service lines related to a single submitted service line on the same claim. The claim splitting process specified in Section 1.10.2.11 - Claim Splitting can not be applied to the parts of an unbundled submitted service. When reporting bundling and unbundling it is required (if submitted on the 837) to maintain the use of the REF*6B Line Item Control Number. This allows the providers to track what happened to each original service line. See Section 1.10.2.11 - Claim Splitting for more information about line item controls.

1.10.2.7 Predetermination of Benefits

Tables 2 and 3 in the 835 also may contain information about future remittances that are to be paid when specified services are completed. The future payment is expressed as an adjustment in one of the CAS segments. Use a Claim Adjustment Group code of OA, "other adjustment," and a Claim Adjustment Reason Code of 101, "predetermination, anticipated payment upon completion of services." A predetermination must balance within a transaction set in the same way that claim payments must balance. Because the payment amount is actually zero now, adjustments must be adequate to reduce the claim balance to zero.

A predetermination is identified by Claim Status Code value 25, "predetermination pricing only -- no payment," in CLP02. Effectively, a predetermination is informational only and can be contained in an 835 that pays other claims.

Example

A provider submits a claim for predetermination of benefits to the PPO for a total claim charge amount of $1000.00. The payer determines that, if the claim is to be paid, the adjustments shown in Table 1.2 - Example Adjustments, are to be applied.

Table 1.2 - Example Adjustments

AdjustmentAmountClaim Adjustment Reason Code
Deductible$50.00Code 1
Coinsurance$200.00Code 2
Exceeded the fee schedule$200.00Code 45

The projected payment amount is then $550.

CLP*1234567890*25*1000*0*250*12*9012345678~
CAS*PR*1*50**2*200~
CAS*CO*45*200~
CAS*OA*101*550~

1.10.2.8 Reversals and Corrections

When the claim adjudication results have been modified from previous reporting, the method for revision is to reverse the entire claim and resend modified data. If any of the service lines within a claim were communicated as pended in the 835 when making a partial payment, the payer must reverse the original payment and resend the data when paying the pended lines. As an alternative to this method a payer may split the claim prior to making the partial payment. See Section 1.10.2.11 - Claim Splitting.

NOTE

Handling reversals internal to the 835 may cause system changes that need to be addressed as part of the implementation plan.

Example

In the original PPO payment, the reported charges were as follows in Table 1.3 - Reported Charges:

Table 1.3 - Reported Charges

Submitted charges$100.00

Adjustments

Disallowed amount

Coinsurance

$20.00

$16.00

Deductible$24.00
Payment amount$40.00

Original Payment

CLP*1234567890*1*100*40*40*12*CLAIM12345~
CAS*PR*1*24**2*16~
CAS*CO*45*20~

The payer found an error in the original claim adjudication that requires a correction. In this case, the disallowed amount should have been $40.00 instead of the original $20.00. The co-insurance amount should have been $12.00 instead of $16.00, and the deductible amount did remain the same.

Reversal Method

Reverse the original payment, restoring the patient accounting system to the pre-posting balance for this patient. Then, the payer sends the corrected claim payment to the provider for posting to the account.

It is anticipated that the provider has the ability to post these reversals electronically, without any human intervention.

Reversing the original claim payment is accomplished with code 22, "reversal of previous payment", Send original Claim Adjustment group codes in CAS01; and appropriate adjustments. All original charge, payment, and adjustment amounts are negated.

For the reversal, include any Supplemental Claim Information (AMT) segment iterations from the original claim payment that relate to interest or prompt payment discounts (qualifiers I and D8). Negate the dollar amount reported on the original claim adjudication. These reversed interest and prompt payment discount entries must be included in the net interest and prompt payment discount payments in the PLB segment. Do not report any other Claim Information (AMT) segments in the reversal claim. See Section 1.10.2.9 - Interest and Prompt Payment Discounts, for additional information.

CLP*1234567890*22*-100*-40**12*CLAIM12345~
CAS*PR*1*-24**2*-16~
CAS*CO*45*-20~

NOTE

The reversal does not contain any patient responsibility amount in CLP.

The corrected claim payment is provided as if it were the original payment. This must include any revised, non-zero, interest or prompt payment discount values in the Supplemental Claim Information (AMT) segment.

CLP*1234567890*1*100*24*36*12*CLAIM12345~
CAS*PR*1*24**2*12~
CAS*CO*45*40~

NOTES

  • Caution, while the claim paid amount (CLP04) for this claim can be zero or less, the reversal method included in Section 1.10.2.8 - Reversals and Corrections, must not cause the total payment for this 835 (BPR02) to become negative.

  • The example does not provide service line detail. If the service line detail had been on the original payment, then the reversal must apply the same reversal logic to the claim and service lines.

  • The CLP07 Payer Claim Control Number in the reversal must be identical to the CLP07 value in the original claim payment.

  • The CLP07 value for the correction claim may be a different value, but the authors recommend using the same value as in the original CLP07 if at all possible. When the CLP07 value for the corrected claim is different than the CLP07 value from the original claim, one iteration of the 2-040REF segment with REF01 equal to F8 (Original Reference number) and REF02 equal to the original CLP07 value is required in the correction claim.

1.10.2.9 Interest and Prompt Payment Discounts

Payer-provider level interest and prompt payment discounts refer to adjustments that specific payer and provider contractual agreements or regulations require. Convey the net for all claims in the remittance advice for interest in the Provider Adjustment Segment using Adjustment Reason code L6. Convey the net for all claims in the remittance advice for prompt payment discount in the Provider Adjustment Segment using Adjustment Reason code 90. Such adjustments are financially independent from the formula for determining benefit payments on behalf of the beneficiary receiving care. Consequently, providers must be able to post these types of adjustments to the general ledger rather than to the patient's account receivable. Additionally, providers must be able to examine the claim-specific information to validate the payer's adjudication calculation.

Convey claim-specific information in the Claim Supplemental Information Segment, AMT. Use code I, for "Interest," or use D8, "discount amount," for a prompt payment discount, in AMT01.

The nature of the financial adjustments conveyed in the PLB segment is identified in PLB03, Composite Adjustment Identifier. The payments can either increase -- reported as a negative number -- or decrease -- reported as a positive number -- the payment. The code values used for interest and prompt pay discounts within the PLB03 composite are as follows:

  • L6 - Interest Owed

Refers to interest adjustments made as part of the contractual agreement for handling claim obligations beyond the timelines established.

  • 90 - Early Payment Discount

Refers to a prompt payment discount or the amount that is allowed for quickly paying a claim according to the terms of the contractual agreement.

In the case of a reversal and correction claim where interest or prompt payment discounts were part of the initial claim adjudication, the reversal claim must include the original interest or prompt payment amounts as negated values in the Claim Supplemental Information AMT segment. The corrected claim then includes the revised interest or prompt payment discount values, if appropriate. See Section 1.10.2.8 - Reversals and Corrections, for additional information.

NOTE

Managed care contracts also can show similar types of adjustments within the Provider Adjustment Segment. See Section 1.10.2.10 - Capitation and Related Payments or Adjustments, for the appropriate managed care references.

Summary

  • Use the PLB for net interest and net prompt pay discounts to reflect payer-provider agreements.

  • Supplemental Claim or Service Amounts in the AMT segments do not influence balancing the Claim or Service Payment loops or balancing the 835 for benefit payments made on behalf of the patient.

  • To reference Interest and prompt payment discounts use codes L6, "interest," and 90, "early payment discount,".

  • If any interest responsibility and/or prompt pay discounts are extended to the patient, report the data in the CAS segment, which impacts CLP04, Claim Payment Amount. Do not report the data in the AMT and PLB segments.

Example

  • Acme Insurance and Dr. Doe (Provider Number 12345) have an agreement whereby Acme pays Dr. Doe a 5% annual percentage rate (.0137% per day) of the claim payment for any claim that is not remitted or denied within 30 days, for each day over 20 days.

  • Melvin Jones (patient) has covered charges of $10,000, submitted electronically to Acme on November 10, 2001.

  • Acme processes the claim and determines that benefits payable are $9,000 with a patient deductible of $1,000.

  • Payment is remitted on January 24, 2002. The amount paid includes interest due for 55 days.

  • The interest amount is $67.81.

Interest information is provided in the Claim Supplemental Information Amounts Segment. The PLB is used to report provider level financial adjustment detail to be used within the balancing routine.

CLP*2528278*1*10000*9000*1000**951910002~
CAS*PR*1*1000~
NM1*QC*1*Jones*Melvin~
AMT*I*67.81~
PLB*12345*20021231*L6*-67.81~

1.10.2.10 Capitation and Related Payments or Adjustments

The 835 is used to provide financial notification of capitation payments from a Managed Care Organization (MCO) to a capitated care provider. The 835 does not contain the capitation details or membership roster. Use an associated Eligibility and Benefits Notification Transaction Set (271) to communicate these details. Capitation payments may be included with claims payment information in a single 835 or they may be passed alone. In either case, the existing balancing process for the 835 applies.

Capitation payments and adjustments are reported in the PLB segment. Individual amounts are reported in PLB04, 06, 08, 10, 12, and 14.

NOTE

A POSITIVE amount reduces payment. A NEGATIVE amount increases payment.

PLB03, 05, 07, 09, 11, and 13 are used to provide the Adjustment Reason Code and the reference number associated with the payments and adjustments. In the case of a capitation payment related to a member list provided in a 271 transaction, the reference number from the Reassociation Key Segment identifying the 271 is provided as a PLB reference number for the appropriate dollar amount.

For identification and explanation purposes, use the following codes in Position 1 of the Composite Adjustment Identifier in the PLB segment.

  • AM - Applied to Borrowers Account

    Loan Repayment is a repayment to the MCO of monies previously paid to the capitated provider for purchasing equipment. The repayment amount is deducted from the usual periodic payment that the provider would otherwise receive from the MCO.

  • BN - Bonus

    Bonus Payment is an additional payment made to a primary care physician or other capitated provider at a set time agreed upon by both parties, usually to recognize performance above usual standards. The bonus payment may be based upon utilization parameters, quality measurements, membership services performed, or other factors.

  • CR - Capitation Interest

    Interest payments represent a percentage payment in excess of the usual amount, paid to the capitated provider as a result of a late payment by the MCO or as a result of funds previously withheld.

  • CT - Capitation Payment

    Capitation Payment is a set dollar amount paid to the primary care physician or other capitated provider selected by the member for the provision of services agreed upon by the provider and the MCO. The dollar amount may be based upon a member's age, sex, specific plan under which the member is enrolled, benefit limitations, or other predetermined factors. The payment is made at periodic set times generally defined in the contractual arrangement between the provider and the MCO.

  • E3 - Withholding

    Withholding is a set dollar amount or percentage of the capitation payment deducted per the contractual agreement between the provider and the MCO. This amount may be returned to the provider at a later date, usually as a result of meeting specific performance requirements defined in the agreement.

  • FC - Fund Allocation

    Fund Allocation is a methodology used to distribute payments made to the primary care or other capitated provider from funds designated for allocation. Funds may be prepaid amounts where deductions are withdrawn over a set period as services are provided.

  • IP - Incentive Premium Payments

    Incentive Premium Payments are additional payments made to a capitated provider to acknowledge high quality services or to provide additional services that are not routinely considered as capitated services by the MCO. This payment also may be used as a financial incentive to sign new providers to the managed care network.

  • L3 - Penalty

    A Penalty is a deduction made in the financial payment to the capitated provider as a result of non-fulfillment of a requirement stipulated in the contractual agreement between the provider and the MCO. Generally, the actual sum forfeited is defined in the agreement.

  • RA - Retro-Activity Adjustment

    Retro-activity payments, adjustments, and notification are given to the capitated provider for an enrolled member who had selected or changed a capitation provider for a time period before the current payment period. This adjustment usually occurs because of late notification from an employer and/or member after the set cutoff time for a capitation payment/notification. This adjustment may result in a payment deduction to the provider in circumstances where the member disenrolled or was terminated from coverage under the MCO during a previous payment period.

  • TL - Third Party Liability

    Third Party Liability indicates that another entity is liable for the payment of health care expenses. The capitation payment may be reduced for the reported time period as a result of the payment from the other responsible party.

For information about reporting encounters in the 835 see Section 1.10.2.19 - Reporting Encounters in the 835.

1.10.2.11 Claim Splitting

A claim submitted to a payer may, due to a payer's adjudication system requirement(s), have service line(s) separated from the original claim. The commonly used term for this process is 'splitting the claim'. Each portion of a claim that has been split has a separate claim control number, assigned by the payer and the sum of the service line(s) charge submitted on each split claim becomes the split claim total charge.

An example of this type of processing is a multi-line claim that contains a service line which requires further information to finalize. By splitting the pending service line to a separate claim, the payer can then adjudicate the remainder of the claim/service lines submitted. Once the split claim is finalized, the adjudication information for the split claim will be returned to the provider.

To assist the provider in reconciling their patient accounts, the payer must retain and return basic original claim information in each of the adjudicated claims. The original Claim Submitter's Identifier (CLM01) must be returned on all split claims in CLP01. The provider's original submitted line item control number from the claim must be returned in the REF segment, loop 2110. If the original claim did not contain a specific line item control number for the service lines, the line item sequence number (LX01) from the original claim must be used in the 835 REF segment instead.

In addition, payers must identify each claim as being part of a split claim by utilizing the MIA or MOA segment with Remittance Advice Remark Code MA15 (Your claim has been separated to expedite handling. You will receive a separate notice for the other services reported) on each of the adjudicated (split) claims. See the MIA and MOA segment detail for specific usage instructions.

1.10.2.12 Balance Forward Processing

A common practice within Health Care claim processing is the review and re-adjudication of claims. This practice sometimes results in additional payments to the provider. Other times it results in a reduction in the payment amount. While the reversal and correction process (see Section 1.10.2.8 - Reversals and Corrections) identifies the process for reporting these changes, one aspect has been left out. Since the 835 is a financial transaction and not just a report, the payment amount can not be negative. The question then arises, what do you do when refunds from reversals and corrections exceed the payments for new claims, resulting in a net negative payment? The answer is Balance Forward Processing.

The PLB segment's ability to report adjustments not related to a specific claim also allows for a balance forward adjustment. This capability allows a payer to move the negative balance from the current 835 transaction into a future transaction. The business objectives are:

Increase the net for the current 835 to $0.00.

Add the previous balance into a future 835 transaction.

Identify to the provider what has happened.

Identify a reference number for reconciliation of the balance forward process.

Moving a negative balance out of the current 835:

When a net negative payment is detected in an 835, this is corrected by adding a balance forwarding adjustment in the PLB segment. While any adjustment pair can be used in the PLB, PLB03 and PLB04 will be used for illustrative purposes. The adjustment reason used in PLB03-1 will be FB, "Forwarding Balance". The reference number in PLB03-2 will contain the same number as the trace number used in TRN02 of the current transaction. This reference number will facilitate tracking by the provider. The dollar amount in PLB04 will be the same as the current, negative, balance. Since the balancing section, Section 1.10.2.1.3 - Transaction Balancing, specifies that the transaction balance is the claim payment total minus the provider level adjustments, the transaction payment amount will now be $0.00. The value in BPR02 will be 0.

Assume that the current net for the transaction for provider "ABA8789" is $-200.00 and that the trace number in TRN02 is "1234554". To move the balance forward, the PLB segment will read:

PLB*ABA8789*20001231*FB:1234554*-200~

Since -200 minus -200 equals 0, the BPR segment will contain 0 in BPR02.

Adding the previously forwarded balance to a new 835:

When a balance forward adjustment was reported in a previous 835, a future 835 must add that money back in order to complete the process. In this case, the PLB segment is again used as the mechanism. PLB03-1 contains FB, "Forwarding Balance". PLB03-2 contains the same reference number from the PLB segment of the previous 835. This allows the receiver to quickly reconcile the two balance forward adjustments. PLB04 contains the same dollar amount as the previous day, but as a positive value. The positive number reduces the payment in this 835.

Continuing the same example, the PLB segment for the next remittance advice for the provider will be:

PLB*1234567894*20001231*FB:1234554*200~

NOTE

The sign of the dollar amount in the PLB segment determines whether the balance forward is moving from today into tomorrow or from yesterday into today.

Balance forward occurs only at the transaction level not at the claim level.

If the net for this new 835 is negative, the balance forward process would be repeated.

Since this is a new 835 with a new balance forward amount, the reference number in the appropriate Adjustment identifier composite (i.e. PLB03-2) will contain the same number as the trace number assigned in TRN02 of this new 835.

1.10.2.13 Secondary Payment Reporting Considerations

Many patients are covered by more than one health plan. In multi-payer situations, a hierarchy is established as to which plan is primary, secondary, or tertiary as applicable for payment of a patient's health care expenses. Secondary and tertiary payers are frequently referred to as "secondary" payers. All previous payer(s) are frequently referred to as the primary payer(s). Most secondary payers adjust their payments so that the total payments, primary and secondary, do not exceed the billed charges for covered services.

Each health plan defines when that plan is primary, secondary, or tertiary for a covered individual. Each payer's plan also generally defines its calculation methodology to determine its payment for services when another payer is primary. The calculation methodology often includes adjustments when the primary allows a higher or lower payment amount for a service than the secondary, if the primary's plan does not cover one or more services on a multi-service claim, if the amounts of deductible or coinsurance differ under the plans, or for other variables. To eliminate a possible disincentive for enrollment in more than one plan, some payers do not consider the full amount of the primary's payment when calculating their secondary payment.

From the perspective of the secondary payer, the "impact" of the primary payer's adjudication is a reduction in the payment amount. This "impact" may be up to the actual amount of the primary payment(s) plus contractual adjustment(s).

Report the "impact" in the appropriate claim or service level CAS segment with reason code 23 (Payment adjusted due to the impact of prior payer(s) adjudication including payments and/or adjustments.), and Claim Adjustment Group Code OA (Other Adjustment). Code OA is used to identify this as an administrative adjustment.

If a secondary payer allows more than the submitted amount the claim must still balance. This is reported as a CAS segment with a group code OA (Other Adjustments) and a reason code of 94 (Processed in Excess of Charges) with a negative dollar amount. From that point, apply all normal CAS adjustments to derive the reimbursement amount.

It is essential that any secondary payer report in the remittance advice only the primary amount that has actually impacted their secondary payment. In many cases, this "impact" is less than the actual primary payment. When this happens, reporting the "actual" payment would prevent the transaction from balancing.

The claim status code in CLP02 must report whether the claim is being processed as primary, secondary, or tertiary. An 835 transaction does not allow a secondary payer to report the "actual" amount of a primary's payment if different than the "impact" amount. Only a primary payer sends that information to a provider.

The AMT segment must be used to report the secondary payer's claim coverage amount or service allowed amount to the provider.

Report secondary claim payments using the following business process (the actual order in the 835 is not being specified):

  1. Report the claim coverage amount or service allowed amount in the claim level AMT segment using qualifier AU (claim level) or B6 (service level) in AMT01.

  2. Report any adjustments related to patient responsibility where the patient is still responsible for the adjusted amount after coordination of benefits with the previous payer(s). (Claim Adjustment Group Code equals PR).

  3. Report any further reduction taken by the current payer as a result of the other payer(s) payment or contractual adjustment(s) (Claim Adjustment Group Code equals OA and Claim Adjustment Reason Code equals 23).

  4. Report any additional contractual obligations, not previously reported by prior payer(s) that may remain after coordinating benefits with the other payer. (Claim Adjustment Group Code equals CO). For example, the secondary payer normally would have a contractual obligation of $200 on the submitted charge. The primary payer only had a contractual reduction of $100 which the secondary payer accounted for with CARC 23. The remaining balance on the expense after coordination is $50. In order to balance the transaction and report to the provider that additional funds need to be written-off, the secondary payer would report the $50 using group code CO and the appropriate CARC.

    NOTE:

    This includes any amounts that would normally have been the patient's responsibility, but are being satisfied by the current payer with amounts paid by the other payer(s).

See Section 3.3 - Business Scenario 3 for detailed examples.

1.10.2.14 Service Line Issues

While previous sections touched upon usage of the service line information, there is a basic philosophy in the 835 related to the service line that is critical to proper use of the 835.

Much of the information usage in the 835 depends upon the context of a particular service. Since the Claim Adjustment Reason Codes used in the CAS segment tend to be more generic than the codes traditionally used by payers, they depend on the context to create a complete message. Information in the SVC segment must frequently work with the Claim Adjustment Reason Codes to give the provider a message that will not result in calls to customer service.

The SVC segment provides two locations for service line procedure information. SVC01 always contains the coding for the procedure used in adjudication. SVC06 contains the original procedure code submitted by the provider when it is different than the coding in SVC01. Use of both of these locations is necessary to maximize administrative simplification benefits.

For instance, when reporting an adjustment for a post operative visit service that is being denied because the payment was included in the payment for the surgery, the CAS and SVC segments must work together to report the complete message. This situation is similar to procedure code bundling, except that one of the submitted services is the adjudicated procedure code. The CAS segment will report an adjustment code of 97 (Payment is included in the allowance for another service/procedure). But, this information is not adequate without reporting the surgery procedure code in SVC01 as well as the post operative procedure code in SVC06.

This ability to report an adjudicated and submitted procedure code must always be implemented to:

  • report changes in coding by the payer.

  • report adjudication decisions based upon a service reported on another line or claim rather that what was submitted by the provider for this line.

1.10.2.14.1 Service Line Splitting

During the adjudication process there may be times when a service line needs to be split. This section explains and shows examples of how service line splitting must be reported in the 835 ERA. This section also differentiates between Service Line Splitting and Unbundling of a service line.

Line splitting reported in the 835 may only be a result of a business issue. Line splitting as a result of an adjudication system limitation (Technical Issue), must be recombined prior to reporting in the 835. To help clarify this, examples of both types of issues are given below.

Business issues:

There may be times when a service line may need to be split by the payer for business reasons.

Examples when service line splitting is necessary include, but are not limited to:

  • The date of service range crosses a change in coverage

  • Some units process under one adjudicated procedure code and others process under a different adjudicated code

  • Some units process under one benefit rate and others process under a different benefit rate

Technical Issues (System Limitations):

Technical limitations are another reason for line splitting within the adjudication system. For example, the adjudication system only handles 2 place positions for units of service therefore 101 units submitted would be split into 99 units and 2 units respectively.

In some payer systems there are limitations on date ranges, forcing lines to be split to separate units by date.

This is not to say that the claims system can not split lines, but they must be recombined on the remittance.

Characteristics of Line Splitting vs Unbundling:

Line Splitting:

  • A submitted service line would be split into multiple lines.

  • Adjudicated Procedure code may or may not be the same as the submitted procedure code across split service lines in the SVC Segment.

  • The sum of the split line units must equal the total submitted units from the original service line.

Unbundling:

  • A submitted service line is reported as more than one SVC segment.

  • The adjudicated procedure code in the SVC segment will always be different than the submitted procedure code. Note: an exception to this is partial unbundling.

  • The sum of the unbundled units of service is greater than the total submitted units from the original service line.

NOTE

When both line splitting and unbundling are required, the payer must first apply the splitting logic, and then the unbundling logic.

Splitting Line Requirements:

When reporting split service lines in the 835 you must:

  • Retain the original submitted procedure code

  • Sum of split lines' units of service must equal the original submitted units of service with each split line.

  • Allocate the submitted charge proportionately by units of service across the split lines. The sum of the split lines' submitted charges must equal the original submitted line charge.

  • Return the line item control number from the original line on all split lines. If no line item control number was received, use the original line item sequence as the line item control number.

  • Report one LQ segment iteration with LQ01 equal to HE and LQ02 equal to N123 (This is a split service and represents a portion of the units from the originally submitted service.)

Example 1

A Provider submitted a claim with one service line for 4 units for a new patient visit. In this situation, the payer decides to split the line into 2 separate lines, one line for the new patient visit and one line for the 3 remaining visits that were down-coded to an established patient visit.

Original Claim

LnCtrl#Procedure CodeDOSSubmitted Chgs.UnitsPaid Amount
01A1/1/02-3/1/02400.004360.00

As processed by Payer

LnCtrl#Procedure CodeDOSSubmitted Chgs.UnitsPaid Amount
01A1/1/02-1/31/02100.001100.00 remark code
01B2/1/02-3/1/02300.003260.00 remark code

835 Example:

SVC*HC:A*100*100**1~
REF*6R*01~
LQ*HE*N123~
SVC*HC:B*300*260**3*A~
CAS*CO*45*40~
REF*6R*01~
LQ*HE*N123~

Example 2

The provider submits a claim for 8 units of service for one procedure code on one service line for dates of service which span the dates of benefit coverage. The payer splits the line into two lines, one line for each benefit period.

Original Claim

LnCtrl#Procedure CodeDOSSubmitted Chgs.UnitsPaid Amount
01A12/1/02-1/30/03800.008

As processed by Payer

LnCtrl#Procedure CodeDOSSubmitted Chgs.UnitsPaid Amount
01A12/1/02-12/31/02400.001400.00 remark code
01A1/1/03-1/30/03400.003360.00 remark code

835 Example:

SVC*HC:A*400*400**4~
REF*6R*01~
LQ*HE*N123~
SVC*HC:A*400*360**4~
CAS*PR*2*40~
REF*6R*01~
LQ*HE*N123~

Line Splitting Across Claims:

An example of Service line splitting: A claim with 5 revenue lines, the lines are split on to two claims, where two of the lines will remain on the original claim, two will be moved to the new claim and the last line will be split between the two claims based on periods of service. Thus, there is no procedure code change and the units remain the same, just split between two claims.

It is possible to have an original claim with split lines that are also split to separate claims. For example, a business reason for splitting a claim is when service line dates of service cross the dates of service of a benefit plan. Another example for splitting the claim is when some lines are going to be pended for further review and other lines are ready to be paid. Additionally these two situations can result in split lines across split claims.

Criteria for split claims and split lines must be maintained in this situation. These are:

  • Claim Submitter's Identification (CLM01) must be returned on all split claims in CLP01.

  • The amount on each claim becomes the split claim total charge.

  • The original submitted line item control number or (when not present) the line item sequence number from the claim must be returned in the service identification REF segment 2110.

  • Remark codes at the service level and claim level are required in this situation.

Original Claim - Patient Control # - 12345

Revenue LineDOSSubmitted Chgs.UnitsPaid Amount
1 A 150.002300.00
2 B 100.004400.00
3 C 50.005250.00
4 D 10.00660.00
5 E9/28-10/0320.00480.00
Total Paid 1090.00

Split Claim: Claim 1

Revenue LineDOSSubmitted Chgs.UnitsPaid Amount
1 A 150.002300.00
2 B 100.004400.00
5 E9/28-9/3020.00240.00
Total This Claim 740.00

835 for Claim 1

CLP*12345*1*740**MC~
MOA**MA15~
SVC*NU:A*300*300**2~
REF*6R*1~
SVC*NU:B*400*400**4~
REF*6R*2~
SVC*NU:E*40*40**2~
DTM*150*20020928~
DTM*151*20020930~
REF*6R*5~
LQ*HE*N123~

Split Claim: Claim 2

Revenue LineDOSSubmitted Chgs.UnitsPaid Amount
3 C 50.005250.00
4 D 10.00660.00
5 E10/01-10/0320.00240.00
Total This Claim 350.00

835 for Claim 2

CLP*12345*1*350**MC~
MOA**MA15~
SVC*NU:C*250*250*5~
REF*6R*3~
SVC*NU:D*60*60**6~
REF*6R*4~
SVC*NU:E*40*40**2~
DTM*150*20021001~
DTM*151*20021003~
REF*6R*5~
LQ*HE*N123~

Total of Both Claims: 1090.00

1.10.2.15 PPOs, Networks and Contract Types

Many payers may encounter a situation where a particular provider has contracted with several different Preferred Provider Organizations, contract types or networks (PPOs) offered by that payer. This transaction set provides a method for communicating to a provider which contract applies to a particular claim.

NOTE

Contract Types includes but is not limited to products and lines of business of the health plan. The specific need for identification is determined by the business alignment of the health plan and how that determines payment to providers rather than any objective concept of network or product line.

When adjusting the claim for the PPO discount, the amount of the adjustment is reported in the CAS segment contained in loop 2100 or 2110, whichever is applicable. The adjustment amount is reported in the CAS segment using group code CO, contractual obligation in CAS01, an appropriate adjustment reason code and amount. The name or identifier of the PPO is reported in REF02 of the Other Claim Related Information REF segment using code CE in REF01. While it is possible that free-form text may be transmitted in the REF segment, it is recommended that each payer develop a standardized list of PPOs (or other payment arrangements), to facilitate automated processing by providers.

For example, assume that Provider P has contracted with two PPOs, A and B. Assume further that the claim was submitted as $75.00 and has been repriced by PPO B to $55.00. The pertinent parts of the claim would then appear as follows:

CAS*CO*45*20~
REF*CE*B~

1.10.2.16 Post Payment Recovery

The 835 is used for the payment of claims to other payers in a post payment recovery situation when there is a clear and legally established subrogation of third party liability. Such a situation includes, but is not limited to, Title XIX of the Social Security Act (Medicaid Program) as contained in Section 1902(a)(25). For a post payment recovery claim the 835 can be used to: make a payment; send an Explanation of Benefits (EOB) remittance advice; or make a payment and send an EOB remittance advice from one health care payer to another health care payer, either directly or through a DFI.

1.10.2.17 Claim Overpayment Recovery

While all health plans strive for accurate adjudication on the first pass, occasionally adjudication mistakes are detected (sometimes through an appeal process) that result in changes to either the amount paid or the allocation of further responsibility for unpaid balances. When the payment increases or the responsibility (contractual obligation versus patient responsibility) changes without a change in payment the reversal and correction process described in Section 1.10.2.8 - Reversals and Corrections describes the necessary actions within the 835. However, when the review results in a reduction of the claim payment amount, the business gets more complicated in how to accomplish an overpayment recovery. Basically, there are three business approaches to claim overpayment recovery. The health plan should specify its methodology for claim overpayment recovery in either a trading partner agreement or a provider contract.

  1. A health plan may choose to recoup the overpayment immediately within the current remittance advice (835). When this is the business model, the reversal and corrections instructions in Section 1.10.2.8 - Reversals and Corrections describe the necessary actions.

  2. A health plan may choose to not recoup the funds immediately and use a manual reporting process to the provider. This process involves sending a letter identifying the claim, the changes to the adjudication, the balance due to the health plan and a statement identifying how long (or if) the provider has to remit that balance. This document must contain a financial control number (FCN) for tracking purposes. Upon receipt of the letter, the provider will manually update the accounts receivable system to record the changes to the claim payment.

If the provider chooses to remit the balance due within the specified time period with a check, the health plan will acknowledge the receipt of the check using the PLB segment of the next 835. In order to maintain a balanced 835, this is accomplished using offsetting adjustments in the PLB. PLB03-1 codes 72 (Authorized Return) and WO (Overpayment Recovery) are used.

Example: A health plan sends a letter to a provider (number 1234) identifying an overpayment of $37.50. The FCN of the document is 56473. Before the specified deadline, the provider remits the overpayment to the health plan, identifying the FCN with the payment. A PLB segment in the next 835 would report this payment.

PLB*1234*20011231*WO:56473*37.5*72:56473*-37.5~

If the provider chooses (or is instructed) to not remit the overpayment by the established deadline, then the health plan will recoup the funds in an appropriate 835. This is accomplished using the PLB segment, and NOT the reversal and correction procedure. Reversal and correction is not appropriate since the provider's system has already been updated manually to reflect the adjudication changes. PLB code WO (Overpayment Recovery) is used to effect the recovery.

This process would also be used if the provider were to remit the funds without the payer initiating the refund.

The payer would acknowledge that the funds were received using the original trace number to indicate which payment the overpayment was from. WO would be used for this situation as well.

Example: A health plan sends a letter to a provider (number 1234) identifying an overpayment of $37.50. The FCN of the document is 56473. The provider does not remit the overpayment to the health plan. A PLB segment in the next 835 would report the overpayment recovery.

PLB*1234*20011231*WO:56473*37.5~
  1. The health plan may use a combination of methods 1 and 2 for overpayment recovery. The reversal and correction process (Section 1.10.2.8 - Reversals and Corrections) would provide the claim specific information. Within the same 835, a PLB segment is then used to return the funds to the provider and NOT reduce the current payment. This is effectively delaying the recovery of funds within the 835. The FCN reported would be the health plan's internal control number for the claim involved in the recovery (CLP07). The external agreement identifying how the health plan is doing overpayment recovery would specify the time period within which the provider may send the payment or that the provider may not send the payment. PLB03-1 code WO (Overpayment Recovery) is used with a negative dollar amount to eliminate the financial impact of the reversal and correction from the current 835. When the payment is received from the provider, or the health plan recoups the funds, the process identified in option 2 is followed to report the payment or recoup the funds, as appropriate.

Example: The health plan re-adjudicates a claim (number 837483) resulting in an overpayment recovery of $37.50 from provider number 1234. The reversal and correction are reported in the 835 (not shown) with a PLB segment to reverse the current financial impact.

PLB*1234*20011231*WO:837483*-37.5~

The provider remits the balance before the deadline identified in the agreement with the health plan. The next 835 reconciles the payment with the previous receivable using the PLB segment.

PLB*1234*20011231*WO:837483*37.5*72:837483*-37.5~

NOTE

If any of the above processes result in an 835 with a negative balance (BPR02), the balance forwarding process identified in Section 1.10.2.12 - Balance Forward Processing is used to eliminate the negative value in BPR02.

1.10.2.18 Totals within the 835

The 835 does not provide extensive totaling of claim payment information. While many older proprietary formats provided this information, the generation of totals is mostly left to the receiver of the transaction, if they desire the information. Since the 835 is expected to be an electronically processed transaction, the totals are seen as an output from that process, rather than as a direct part of the 835.

The total that is always included in the 835 is the total paid amount in the BPR02. In instances where the business situation requires use of the TS3 segment, the TS3 segment will provide total number of claims for a 2000 loop in TS304 and the total claim charge in TS305.

Some of the other totals that can be calculated are described below. This is not an all inclusive list. Other desired totals can be calculated in similar ways.

Total Number of Claims - count of the number of CLP segments in the 835.

Total Claim Charge - sum of the CLP03 values in the 835.

Total Covered Charge - sum of all AMT02 values where AMT01 equals "AU". See the note in the Claim Supplemental Information AMT01, code "AU" for additional information.

Total Non-Covered Charge - sum of the CAS03, 6, 9, 12, 15 & 18 values in the appropriate 2000 loop where CAS02, 5, 8, 11, 14 or 17 equals values desired by the provider as defining "non-covered charges". The term non-covered charges includes various portions of the rejected claim charge, depending upon interpretation. For example, specific Claim Adjustment Reason codes that can be included here are 47, 49, 50, 51, 53, 54, 60, 78, 96, 111, 117, B1, B8, B9, B11, B14, and 119. Please see the code list for the various definitions. The general code for non-covered charges is 96.

Total Claim Provider Payment - sum of the CLP04 values in the appropriate 2000 loop.

Total Provider Patient Responsibility Amount - sum of the CLP05 values in the appropriate 2000 loop.

Total Interest - PLB04, 6, 8, 10, 12 & 14 when the related adjustment Reason code is "L6".

Total Provider Contractual Obligation Adjustment - sum of the CAS03, 6, 9, 12, 15 & 18 values in the appropriate 2000 loop where CAS01 equals "CO". The desired amount may be refined by providers based upon specific Adjustment Reason Code information, if appropriate.

Total Coinsurance Amount -- sum of the CAS03, 6, 9, 12, 15 & 18 values in the appropriate 2000 loop where CAS02, 5, 8, 11, 14 or 17 equals value "2".

Total Deductible Amount - sum of the CAS03, 6, 9, 12, 15 & 18 values in the appropriate 2000 loop where CAS02, 5, 8, 11, 14 or 17 equals value "1".

1.10.2.19 Reporting Encounters in the 835

Encounters (services covered under a capitation agreement between the payer and the provider) present special challenges in the 835. Whether a specific encounter is really an encounter is a complicated issue. To be an encounter for 835 purposes, both the payer and provider must agree that the claim and/or service is an encounter. The payer identifies this through adjudication. Submitters may indicate 837 transaction contains all encounters by providing the value 'RP' BHT06. When BHT06 equals 'CH', the transaction may or may not include some encounters in addition to chargeable claims.

This leads to 3 scenarios.

  1. A pure encounter claim - Pure encounter claims do not need to be reported in the 835. If the claim was submitted as all encounters and the payer agrees that it was all encounters then no response is sent in the 835. Conversely, if a claim was submitted as all encounters, through use of the BHT segment, and the payer does not agree that it was all encounters, then a response must be sent in the 835.

  2. A mixed claim - If a claim was submitted with some encounter services and some payable services, the payer is obligated to return all received services that were submitted with a charge greater than $0.00 and any $0.00 services that were identified as payable during adjudication.

    The payer is able to report payment of $0.00 services by using Claim Adjustment Reason Code 94 (Processed in excess of charges) and a negative dollar amount representing the payer's allowed amount for that service.

    Additional adjustments to identify patient responsibility for deductible, copay or other adjustments would also be provided. Any services reported with a $0.00 charge and identified as capitated services by the payer do not need to be returned in the 835.

  3. All payable claim - If a claim is submitted with all charges >$0.00 (and was not part of a submission identified as all encounters using BHT), the payer is obligated to return all services. Services that the payer determines are covered under the capitation agreement must be adjusted to $0.00 payment using Claim Adjustment Reason Code 24 (Payment for charges adjusted. Charges covered under a capitation agreement/managed care plan).

NOTE

This section does not change the ability to report inpatient claims without service detail when payment is made at the claim level as described in Section 1.10.2.4 - Claim Adjustment and Service Adjustment Segment Theory (Institutional-Specific Use).

Chapter 2. Transaction Set

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

2.1 Presentation Examples

The ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

2.3 Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

2.4 Segment Detail

There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

Segment Key - Element Summary

2.2 Implementation Usage

2.2.1 Industry Usage

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

Required

This loop/segment/element must always be sent.

Required segments in Situational loops only occur when the loop is used.

Required elements in Situational segments only occur when the segment is used.

Required component elements in Situational composite elements only occur when the composite element is used.

Not Used

This element must never be sent.

Situational

Use of this loop/segment/element varies, depending on data content and business context as described in the defining rule. The defining rule is documented in a Situational Rule attached to the item.

There are two forms of Situational Rules.

The first form is "Required when <explicit condition statement>. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver." The data qualified by such a situational rule cannot be required or requested by the receiver, transmission of this data is solely at the sender's discretion.

The alternative form is "Required when <explicit condition statement>. If not required by this implementation guide, do not send." The data qualified by such a situational rule cannot be sent except as described in the explicit condition statement.

2.2.1.1 Transaction Compliance Related to Industry Usage

A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.

Required

Business condition: N/A

Item is Transaction complies with implementation guide?
Sent Yes
Not Sent No
Not Used

Business condition: N/A

Item is Transaction complies with implementation guide?
Sent No
Not Sent Yes
Situational (Required when [explicit condition statement])

If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.

Business Condition is Item is Transaction complies with implementation guide?
True Sent Yes
Not Sent No
Not True Sent Yes
Not Sent Yes
Situational (Required when [explicit condition statement])

If not required by this implementation guide, do not send.

Business Condition is Item is Transaction complies with implementation guide?
True Sent Yes
Not Sent No
Not True Sent No
Not Sent Yes

2.2.2 Loops

Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.

  • A nested loop can be used only when the associated higher level loop is used.

  • The usage of a loop is the same as the usage of its beginning segment.

    • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.

    • If a loop's beginning segment is Situational, the loop is Situational.

  • Subsequent segments within a loop can be sent only when the beginning segment is used.

  • Required segments in Situational loops occur only when the loop is used.

Chapter 3. Examples

3.1 Business Scenario 1

Dollars and data are being sent together through the banking system to pay Medicare Part A institutional claims.

This scenario depicts the use of the ANSI ASC X12 835 in a governmental institutional environment. The electronic transmission of funds request and the remittance detail are contained within this single 835. In this scenario, one or more Depository Financial Institutions is involved in transferring information from the sender to the receiver.

3.1.1 Assumptions

The following assumptions pertain to scenario one:

  • The dollars move using the ACH network from the Bank of Payorea, ABA# 999999992, account number 123456 to the Bank of No Return, ABA# 999988880, checking account number 98765. The money moves on September 13, 2002.

  • The Insurance Company of Timbucktu, Federal tax ID # 512345678 andMedicare Intermediary ID# 999, is paying Regional Hope Hospital, NationalProvider Number 6543210903. This is for one inpatient and one outpatient claim.

  • For the inpatient claim, the patient's name is Sam O. Jones. TheHealth Insurance Claim Number is 666-66-6666A. The Claim Submitter's Identifieris 666123. The date of the hospitalization was August 16, 2002 to August 24,2002. Total charges reported are $211,366.97. Paid amount is $138,018.40. Thereis no patient responsibility. Contractual adjustment is $73,348.57. No serviceline detail is provided.

  • For the outpatient claim, the patient's name is Liz E. Border,Health Insurance Claim Number 996-66-9999B. The Claim Submitter's Identifier is777777. The date of service is May 12, 2002. Total charges reported are $15,000.Paid amount is $11,980.33. Contractual adjustment is $3,019.67. There is noservice line information.

  • There is a Capital Pass Through Amount (CV) payment to the provider for $1.27.

3.1.2 Transmission

ST*835*1234~
BPR*C*150000*C*ACH*CTX*01*999999992*DA*123456*1512345678**01*999988880*DA*98765*20020913~
TRN*1*12345*1512345678~
DTM*405*20020916~
N1*PR*INSURANCE COMPANY OF TIMBUCKTU~
N3*1 MAIN STREET~
N4*TIMBUCKTU*AK*89111~
REF*2U*999~
N1*PE*REGIONAL HOPE HOSPITAL*XX*6543210903~
LX*110212~
TS3*6543210903*11*20021231*1*211366.97****138018.4**73348.57~
TS2*2178.45*1919.71**56.82*197.69*4.23~
CLP*666123*1*211366.97*138018.4**MA*1999999444444*11*1~
CAS*CO*45*73348.57~
NM1*QC*1*JONES*SAM*O***HN*666666666A~
MIA*0***138018.4~
DTM*232*20020816~
DTM*233*20020824~
QTY*CA*8~
LX*130212~
TS3*6543210909*13*19961231*1*15000****11980.33**3019.67~
CLP*777777*1*15000*11980.33**MB*1999999444445*13*1~
CAS*CO*45*3019.67~
NM1*QC*1*BORDER*LIZ*E***HN*996669999B~
MOA***MA02~
DTM*232*20020512~
PLB*6543210903*20021231*CV:CP*-1.27~
SE*28*1234~

3.2 Business Scenario 2

Dollars and data are sent separately. Scenario 2 depicts the use of the 835 in a managed care environment. The funds are moved separately from the remittance detail. In this scenario, the funds are sent by EFT to the provider's account, and the remittance data is transmitted directly to the provider.

3.2.1 Assumptions

The following assumptions pertain to scenario two:

  • The dollars move from the Hudson River Bank, ABA# 888999777, account number 24681012 to the Amazon Bank, ABA# 111333555, checking account number 144444 using the ACH network. The money moves on March 16, 2002.

  • The insurance company, Rushmore Life, Federal Tax ID # 935665544, is paying ACME Medical Center, Nation Provider ID 5544667733 ;& Federal Tax ID # 777667755, a total of $945.00. Rushmore Life and ACME Medical Center have an agreement that a certain portion of their payments will be withheld for future use as specified in their managed medical contract.

  • The first patient's name is William Budd, patient number 5554555444 and member ID # 33344555510. Total reported charges are $800.00. Amount paid is $450.00. Patient responsibility is $300.00. Contractual adjustment (for withhold amount) is $50.00. The service code for the procedure performed is CPT code 99211. The service start date is March 1, 2002. The service end date is March 4, 2002.

  • The second patient's name is Susan Settle, patient number 8765432112 and member ID # 44455666610. Total reported charges are $1200.00. Amount paid is $495.00. Patient responsibility is $600.00. Contractual adjustment is $50.00. Contractual adjustment (for withhold amount) was $55.00. The procedure code for the service performed is CPT code 93555. The service start date is March 10, 2002. The service end date is March 12, 2002.

3.2.2 Transmission

ST*835*112233~
BPR*I*945*C*ACH*CCP*01*888999777*DA*24681012*1935665544**01*111333555*DA*144444*20020316~
TRN*1*71700666555*1935665544~
DTM*405*20020314~
N1*PR*RUSHMORE LIFE~
N3*10 SOUTH AVENUE~
N4*RAPID CITY*SD*55111~
N1*PE*ACME MEDICAL CENTER*XX*5544667733~
REF*TJ*777667755~
LX*1~
CLP*5554555444*1*800*450*300*12*94060555410000~
CAS*CO*A2*50~
NM1*QC*1*BUDD*WILLIAM****MI*33344555510~
SVC*HC:99211*800*500~
DTM*150*20020301~
DTM*151*20020304~
CAS*PR*1*300~
CLP*8765432112*1*1200*495*600*12*9407779923000~
CAS*CO*A2*55~
NM1*QC*1*SETTLE*SUSAN****MI*44455666610~
SVC*HC:93555*1200*550~
DTM*150*20020310~
DTM*151*20020312~
CAS*PR*1*600~
CAS*CO*45*50~
SE*25*112233~

3.3 Business Scenario 3

Regardless of which COB methodology is used to derive a subsequent payment, the following examples provide illustrations of how to report secondary or tertiary payments back to the provider that will facilitate auto-posting.

Considerations used in each example:

  1. What was the primary payer's payment?

  2. What is the amount, after COB that the patient is responsible to payfor the service?

  3. What was the impact of the primary payer's handling of the claim(payment and contractual adjustments) upon the current payer's benefitdetermination?

  4. What amount, if any, does the provider still need to write-off(contractual obligations)?

3.3.1 Assumptions

In the first claim, YTDAW (Your Tax Dollars at Work) payer receives the claim as secondary with a submitted charge of $10323.64. The primary payer (Old World Insurance, a Medicare carrier) allowed $8441.31 of the total submitted charges. A deductible of $912.00 and a contractual adjustment of $1882.33 were applied. The primary payer paid $7529.31 of the submitted charges.

YTDAW, as the secondary payer, is only required to pay the deductible based on the coverage of this contract. After the $912.00 payment is made, the patient, William Peter Townsend does not have a balance due for this provider.

In the second claim, YTDAW payer received a claim as secondary for Angi Baki with a submitted charge of $751.50 for two services rendered. The primary payer (Patients United Health) allowed for one service but denied the other as a noncovered procedure. The amount charged for the covered procedure was $166.50 and $150.00 was allowed. The primary payer paid $120.00 with $30.00 coinsurance due and a contractual adjustment of $16.50. The charge for the non-covered service was $585.00; therefore, the total patient responsibility was $615.00.

YTDAW as the secondary payer allowed $650.00 for the total submitted charges. Thesecondary payer allowed $150.00 for one service and $500.00 for the other service. Thepatient owed a deductible of $150.00 and YTDAW paid $310.00 for this claim. The impactof the primary payer's payment upon the secondary payment is $136.50 (the $16.50contractual adjustment plus their $120.00 payment). After reviewing all of theadjustments, the provider still has an $85.00 contractual adjustment based on YTDAW'sfee schedule with this provider.

3.3.1.1 Transmission

ST*835*0001~
BPR*I*1222*C*CHK************20050412~
TRN*1*0012524965*1559123456~
REF*EV*030240928~
DTM*405*20050412~
N1*PR*YOUR TAX DOLLARS AT WORK~
N3*481A00 DEER RUN ROAD~
N4*WEST PALM BCH*FL*11114~
N1*PE*ACME MEDICAL CENTER*FI*599944521~
N3*PO BOX 863382~
N4*ORLANDO*FL*55115~
REF*PQ*10488~
LX*1~
CLP*L0004828311*2*10323.64*912**12*05090256390*11*1~
CAS*OA*23*9411.64~
NM1*QC*1*TOWNSEND*WILLIAM*P***MI*XXX123456789~
NM1*82*2*ACME MEDICAL CENTER*****BD*987~
DTM*232*20050303~
DTM*233*20050304~
AMT*AU*912~
LX*2~
CLP*0001000053*2*751.50*310*220*12*50630626430~
NM1*QC*1*BAKI*ANGI****MI*456789123~
NM1*82*2*SMITH JONES PA*****BS*34426~
DTM*232*20050106~
DTM*233*20050106~
SVC*HC>12345>26*166.5*30**1~
DTM*472*20050106~
CAS*OA*23*136.50~
REF*1B*43285~
AMT*AU*150~
SVC*HC>66543>26*585*280*220*1~
DTM*472*20050106~
CAS*PR*1*150**2*70~
CAS*CO*42*85~
REF*1B*43285~
AMT*AU*500~
SE*38*0001~

3.3.2 Assumptions

This is an example of a tertiary payment. The patient, Ellis E. Island, has three insurance companies. The total charge for his claim is $1766.50. The primary payer allowed $1600.00 and applied a contractual adjustment of $166.50 as part of the provider's fee schedule. The allowed amount was paid at 80% after a $500.00 deductible was applied. The primary payer paid $880.00.

The secondary payer also allowed $1600.00 for the total submitted charge of $1766.50.The secondary payer calculated their payment as primary to determine the difference inpaying primary versus secondary. After evaluating the primary payment of $880.00, thesecondary payer paid $310.00. The impact of the primary payer's payment upon thesecondary payment is $1046.50 (their contractual adjustment of $166.50 plus their$880.00 payment).

YTDAW as the tertiary payer allowed $1700.00 of the submitted $1766.50 charge. Thetertiary payer also calculated their payment as primary and determined that the totalamount that could be paid was $1377.50. After evaluating the primary and secondarypayments and adjustments, YTDAW paid $187.50. The impact of the primary and secondarypayer's payments upon the tertiary payment is $1356.580 (primary amount of $1046.50 andsecondary amount of $310.00). Therefore, total remaining patient balance for theprovider is $222.50.

3.3.2.1 Transmission

ST*835*0001~
BPR*I*187.50*C*CHK************20050412~
TRN*1*0012524879*1559123456~
REF*EV*030240928~
DTM*405*20050412~
N1*PR*YOUR TAX DOLLARS AT WORK~
N3*481A00 DEER RUN ROAD~
N4*WEST PALM BCH*FL*11114~
N1*PE*ACME MEDICAL CENTER*FI*599944521~
N3*PO BOX 863382~
N4*ORLANDO*FL*55115~
REF*PQ*10488~
LX*1~
CLP*0001000054*3*1766.5*187.50**12*50580155533~
NM1*QC*1*ISLAND*ELLIS*E****MI*789123456~
NM1*82*2*JONES JONES ASSOCIATES*****BS*AB34U~
DTM*232*20050120~
SVC*HC*24599*1766.5*187.50**1~
DTM*472*20050120~
CAS*OA*23*1579~
REF*1B*44280~
AMT*AU*1700~
SE*38*0001~

3.3.3 Assumptions

In this claim, the primary payer received a claim for $541.00. They allowed $400 and paid $375.00 of the submitted charges. The primary payer applied $141.00 as a contractual adjustment that was part of the provider's fee schedule. The patient, Raymond Burck owed a co-pay of $25.00.

YTDAW as the secondary payer allowed $550.00 for the service submitted. This amount is $9.00 more than charged. The secondary payer paid $34.00. The impact of the primary payer's payment on the secondary payer is $516.00 ($141.00 contractual adjustment and $375.00 payment).

3.3.3.1 Transmission

ST*835*0001~
BPR*I*34.00*C*CHK************20050318~
TRN*1*0063158ABC*1566339911~
REF*EV*030240928~
DTM*405*20050318~
N1*PR*YOUR TAX DOLLARS AT WORK~
N3*481A00 DEER RUN ROAD~
N4*WEST PALM BCH*FL*11114~
N1*PE*ATONEWITHHEALTH*FI*3UR334563~
N3*3501 JOHNSON STREET~
N4*SUNSHINE*FL*12345~
REF*PQ*11861~
LX*1~
CLP*0001000055*2*541*34**12*50650619501~
NM1*QC*1*BURCK*RAYMOND*W***MI*987654321~
NM1*82*2*PROFESSIONAL TEST 1*****BS*34426~
DTM*232*20050202~
DTM*233*20050202~
SVC*HC>55669*541*34**1~
DTM*472*20050202~
CAS*OA*23*516~
CAS*OA*94*-9~
REF*1B*44280~
AMT*AU*550~
SE*38*0001~

Appendix A. External Code Sources

A.1 External Code Sources

Appendix A is a listing of all external code sources referenced in this implementation guide.

  • Where an external code source is referenced, the implementer isrequired to use only the codes from that list.

  • If a subset of the code list is listed in the IG, the implementer isrequired to use only the codes from that subset.

  • Codes must be reported as listed in the code source (e.g. with leadingzeroes).

  • Implementers must follow the instructions for code use that aresupplied by the code set owner.

4 ABA Routing Number

SIMPLE DATA ELEMENT/CODE REFERENCES

20, 66/13, 506/01, 647/806

SOURCE

Key to American Bankers Association Routing Numbers

AVAILABLE FROM

Rand McNally & Company

P. O. Box 7600

Chicago, IL 60680

ABSTRACT

Contains the Federal Reserve Routing Codes. The first four digits identify the Federal Reserve District, the next four the institution, and the last is acheck digit.

5 Countries, Currencies and Funds

SIMPLE DATA ELEMENT/CODE REFERENCES

26, 100, 1715, 66/38, 235/CH, 955/SP

SOURCE

Codes for Representation of Names of Countries, ISO 3166-(LatestRelease)

Codes for Representation of Currencies and Funds, ISO 4217-(LatestRelease)

AVAILABLE FROM

American National Standards Institute

25 West 43rd Street, 4th Floor

New York, NY 10036

ABSTRACT

Part 1 (Country codes) of the ISO 3166 international standard establishes codes that represent the current names of countries, dependencies, and other areas of special geopolitical interest, on the basis of lists of country names obtained from the United Nations. Part 2 (Country subdivision codes) establishes a code that represents the names of the principal administrative divisions, or similar areas, of the countries, etc. included in Part 1. Part 3 (Codes for formerly used names of countries) establishes a code that represents non-current country names, i.e., the country names deleted from ISO 3166 since its first publication in 1974. Most currencies are those of the geopolitical entities that are listed in ISO 3166 Part 1, Codes for the Representation of Names of Countries. The code may be a three-character alphabetic or three-digit numeric. The two leftmost characters of the alphabetic code identify the currency authority to which the code is assigned (using the two character alphabetic code from ISO 3166 Part 1, if applicable). The rightmost character is a mnemonic derived from the name of the major currency unit or fund. For currencies not associated with a single geographic entity, a specially-allocated two-character alphabetic code, in the range XA to XZ identifies the currency authority. The rightmost character is derived from the name of the geographic area concerned, and is mnemonic to the extent possible. The numeric codes are identical to those assigned to the geographic entities listed in ISO 3166 Part 1. The range 950-998 is reserved for identification of funds and currencies not associated with a single entity listed in ISO 3166 Part 1.

22 States and Provinces

SIMPLE DATA ELEMENT/CODE REFERENCES

156, 66/SJ, 235/A5, 771/009

SOURCE

U.S. Postal Service or

Canada Post or

Bureau of Transportation Statistics

AVAILABLE FROM

The U.S. state codes may be obtained from:

U.S. Postal Service

National Information Data Center

P.O. Box 2977

Washington, DC 20013

www.usps.gov

The Canadian province codes may be obtained from:

http://www.canadapost.ca

The Mexican state codes may be obtained from:

www.bts.gov/ntda/tbscd/mex-states.html

ABSTRACT

Provides names, abbreviations, and two character codes for thestates, provinces and sub-country divisions as defined by the appropriate governmentagency of the United States, Canada, and Mexico.

51 ZIP Code

SIMPLE DATA ELEMENT/CODE REFERENCES

116, 66/16, 309/PQ, 309/PR, 309/PS, 771/010

SOURCE

National ZIP Code and Post Office Directory, Publication 65

The USPS Domestic Mail Manual

AVAILABLE FROM

U.S Postal Service

Washington, DC 20260

New Orders

Superintendent of Documents

P.O. Box 371954

Pittsburgh, PA 15250-7954

ABSTRACT

The ZIP Code is a geographic identifier of areas within the UnitedStates and its territories for purposes of expediting mail distribution by the U.S.Postal Service. It is five or nine numeric digits. The ZIP Code structure divides theU.S. into ten large groups of states. The leftmost digit identifies one of these groups.The next two digits identify a smaller geographic area within the large group. The tworightmost digits identify a local delivery area. In the nine-digit ZIP Code, the fourdigits that follow the hyphen further subdivide the delivery area. The two leftmostdigits identify a sector which may consist of several large buildings, blocks or groupsof streets. The rightmost digits divide the sector into segments such as a street, ablock, a floor of a building, or a cluster of mailboxes. The USPS Domestics Mail Manualincludes information on the use of the new 11-digit zip code.

60 (DFI) Identification Number

SIMPLE DATA ELEMENT/CODE REFERENCES

507

SOURCE

a) Thompson Bank Directory: American Bankers Association (ABA)Routing Numbers

b) New York Clearinghouse Association: Clearinghouse Interbank PaymentSystem (CHIPS) Participant Numbers

c) Canadian Payments Association Directory: Canadian Bank Transit Numbers

d) ISO/S.W.I.F.T. Bank Identifier Code Directory: ISO Bank IdentifierCodes

AVAILABLE FROM

a) Thompson Financial Publishing

P.O. Box 65

Skokie, IL 60076-0065

b) New York Clearinghouse Association

450 West 33rd Street

New York, New York 10001

c) Bowne of Toronto

60 Gervais Drive

Toronto, Ontario

Canada M3C 1Z3

d) S.W.I.F.T. SC

Avenue Adele 1

B-1310 La Hulpe

Belgium

ABSTRACT

Assigned alphanumeric codes identifying depository financialinstitution.

91 Canadian Financial Institution Branch and Institution Number

SIMPLE DATA ELEMENT/CODE REFERENCES

66/CF, 128/04, 506/04, 647/806

SOURCE

Canadian Payments Association (CPA) Financial InstitutionDirectories

Volume 1 - Banks

Volume 2 - Credit Unions and Caisses PopulairesVolume 3 - TrustCompanies, Loan Companies and other Deposit-taking Institutions

AVAILABLE FROM

Bowne of Canada, Ltd.

60 Gervais Drive

Toronto, Ontario M3C 1Z3

Canada

ABSTRACT

Contains the Canadian financial institutions transit and branchnumbers. The first four digits represent the financial institution ID.

121 Health Industry Number

SIMPLE DATA ELEMENT/CODE REFERENCES

66/21, 128/HI, 1270/HI, I05/20

SOURCE

Health Industry Number Database

AVAILABLE FROM

Health Industry Business Communications Council

5110 North 40th Street

Phoenix, AZ 85018

ABSTRACT

The HIN is a coding system, developed and administered by theHealth Industry Business Communications Council, that assigns a unique code number tohospitals other provider organizations, and manufacturers and distributors.

130 Healthcare Common Procedural Coding System

SIMPLE DATA ELEMENT/CODE REFERENCES

235/HC, 1270/BO, 1270/BP

SOURCE

Healthcare Common Procedural Coding System

AVAILABLE FROM

Centers for Medicare & Medicaid Services

7500 Security Boulevard

Baltimore, MD 21244

ABSTRACT

HCPCS is Centers for Medicare & Medicaid Service's (CMS) coding scheme to group procedures performed for payment to providers.

132 National Uniform Billing Committee (NUBC) Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/NU, 235/RB, 1270/BE, 1270/BG, 1270/BH, 1270/BI, 1270/NUB

SOURCE

National Uniform Billing Data Element Specifications

AVAILABLE FROM

National Uniform Billing Committee

American Hospital Association

One North Franklin

Chicago, IL 60606

ABSTRACT

Revenue codes are a classification of hospital charges in astandard grouping that is controlled by the National Uniform Billing Committee.

135 American Dental Association

SIMPLE DATA ELEMENT/CODE REFERENCES

1361, 235/AD, 1270/JO, 1270/JP, 1270/TQ, 1270/AAY

SOURCE

Current Dental Terminology (CDT) Manual

AVAILABLE FROM

Salable Materials

American Dental Association

211 East Chicago Avenue

Chicago, IL 60611-2678

ABSTRACT

The CDT manual contains the American Dental Association's codes fordental procedures and nomenclature and is the accepted set of numeric codes anddescriptive terms for reporting dental treatments and descriptors.

139 Claim Adjustment Reason Code

SIMPLE DATA ELEMENT/CODE REFERENCES

1034

SOURCE

National Health Care Claim Payment/Advice Committee Bulletins

AVAILABLE FROM

Blue Cross/Blue Shield Association

Interplan Teleprocessing Services Division

676 N. St. Clair Street

Chicago, IL 60611

ABSTRACT

Bulletins describe standard codes and messages that detail thereason why an adjustment was made to a health care claim payment by the payer.

229 Diagnosis Related Group Number (DRG)

SIMPLE DATA ELEMENT/CODE REFERENCES

1354, 1270/DR

SOURCE

Federal Register and Health Insurance Manual 15 (HIM 15)

AVAILABLE FROM

Superintendent of Documents

U.S. Government Printing Office

Washington, DC 20402

ABSTRACT

A patient classification scheme that clusters patients intocategories on the basis of patient's illness, diseases, and medical problems.

235 Claim Frequency Type Code

SIMPLE DATA ELEMENT/CODE REFERENCES

1325

SOURCE

National Uniform Billing Data Element Specifications Type of BillPosition 3

AVAILABLE FROM

National Uniform Billing Committee

American Hospital Association

One North Franklin

Chicago, IL 60606

ABSTRACT

A variety of codes explaining the frequency of the billsubmission.

240 National Drug Code by Format

SIMPLE DATA ELEMENT/CODE REFERENCES

235/N1, 235/N2, 235/N3, 235/N4, 235/N5, 235/N6, 1270/NDC

SOURCE

Drug Establishment Registration and Listing Instruction Booklet

AVAILABLE FROM

Federal Drug Listing Branch HFN-315

5600 Fishers Lane

Rockville, MD 20857

ABSTRACT

Publication includes manufacturing and labeling information as wellas drug packaging sizes.

245 National Association of Insurance Commissioners (NAIC) Code

SIMPLE DATA ELEMENT/CODE REFERENCES

128/NF

SOURCE

National Association of Insurance Commissioners Company Code ListManual

AVAILABLE FROM

National Association of Insurance Commission Publications Department

12th Street, Suite 1100

Kansas City, MO 64105-1925

ABSTRACT

Codes that uniquely identify each insurance company.

307 National Council for Prescription Drug Programs Pharmacy Number

SIMPLE DATA ELEMENT/CODE REFERENCES

128/D3

SOURCE

National Council for Prescription Drug Programs (NCPDP) ProviderNumber Database and Listing

AVAILABLE FROM

National Council for Prescription Drug Programs (NCPDP)

9240 East Raintree Drive

Scottsdale, AZ 85260

ABSTRACT

A unique number assigned in the U.S. and its territories toindividual clinic, hospital, chain, and independent pharmacy and dispensing physicianlocations that conduct business by billing third-party and dispensing physicianlocations that conduct business by billing third-party drug benefit payers. The NationalCouncil for Prescription Drug Programs (NCPDP) maintains this database. The NCPDPProvider Number is a seven-digit number with the following format SSNNNNC, whereSS=NCPDP assigned state code number, NNNN=sequential numbering scheme assigned topharmacy locations, and C=check digit caluculate by algorithm from previous sixdigits.

411 Remittance Advice Remark Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

1270/HE

SOURCE

Centers for Medicare and Medicaid Services

OIS/BSOG/DDIS,

Mail stop N2-13-16

7500 Security Boulevard

Baltimore, MD 21244

AVAILABLE FROM

Washington Publishing Company

http://www.wpc-edi.com/

ABSTRACT

Remittance Advice Remark Codes (RARC) are used to conveyinformation about claim adjudication. It could provide general information orsupplemental explanations to an adjustment already reported by a Claim Adjustment ReasonCode.

468 Ambulatory Payment Classification

SIMPLE DATA ELEMENT/CODE REFERENCES

128/APC

SOURCE

Ambulatory Payment Classification Manual

AVAILABLE FROM

Centers for Medicare and Medicaid Services

Division of Outpatient Care

7500 Security Boulevard

Baltimore, MD 21244

ABSTRACT

Under the outpatient prospective payment system (OPPS), Medicarepays for hospital outpatient services on a rate per service basis that varies accordingto the ambulatory payment classification group to which the service is assigned.

513 Home Infusion EDI Coalition (HIEC) Product/Service Code List

SIMPLE DATA ELEMENT/CODE REFERENCES

235/IV, 1270/HO

SOURCE

Home Infusion EDI Coalition (HIEC) Coding System

AVAILABLE FROM

HIEC Chairperson

HIBCC (Health Industry Business Communications Council)

5110 North 40th Street

Suite 250

Phoenix, AZ 85018

ABSTRACT

This list contains codes identifying home infusion therapyproducts/services.

530 National Council for Prescription Drug Programs Reject/Payment Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

1270/RX

SOURCE

National Council for Prescription Drug Programs Data Dictionary

AVAILABLE FROM

NCPDP

9240 East Raintree Drive

Scottsdale, AZ 85260

ABSTRACT

A listing of NCPDPs payment and reject reason codes, theexplanation of the code, and the field number in error (if rejected).

537 Centers for Medicare and Medicaid Services National Provider Identifier

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XX, 128/HPI

SOURCE

National Provider System

AVAILABLE FROM

Centers for Medicare and Medicaid Services

Office of Financial Management

Division of Provider/Supplier Enrollment

C4-10-07

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid Services is developing theNational Provider Identifier (NPI), which has been proposed as the standard uniqueidentifier for each health care provider under the Health Insurance Portability andAccountability Act of 1996.

540 Centers for Medicare and Medicaid Services PlanID

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XV, 128/ABY

SOURCE

PlanID Database

AVAILABLE FROM

Centers for Medicare and Medicaid Services

Center of Beneficiary Services, Membership Operations Group

Division of Benefit Coordination

S1-05-06

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid Services has joined withother payers to develop a unique national payer identification number. The Centers forMedicare and Medicaid Services is the authorizing agent for enumerating payers throughthe services of a PlanID Registrar. It may also be used by other payers on a voluntarybasis.

576 Workers Compensation Specific Procedure and Supply Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/ER

SOURCE

IAIABC Jurisdiction Medical Bill Report Implementation Guide

AVAILABLE FROM

IAIABC EDI Implementation Manager

International Association of Industrial Accident Boards and Commissions

8643 Hauses - Suite 200

87th Parkway

Shawnee Mission, KS 66215

ABSTRACT

The IAIABC Jurisdiction Medical Bill Report Implementation Guidedescribes the requirements for submitting and the data contained within a jurisdictionmedical report. The Implementation Guide includes: Reporting scenarios, datadefinitions, trading partner requirements tables, reference to industry codes, andIAIABC maintained code lists.

716 Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities

SIMPLE DATA ELEMENT/CODE REFERENCES

235/HP

SOURCE

Health Insurance Prospective Payment System (HIPPS) Rate Code forSkilled Nursing Facilities

AVAILABLE FROM

Division of Institutional Claims Processing

Centers for Medicare and Medicaid Services

C4-10-07

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid services develops andpublishes the HIPPS codes to establish a coding system for claims submission and claimspayment under prospective payment systems. These codes represent the case mixclassification groups that are used to determine payment rates under prospective paymentsystems. Case mix classification groups include, but may not be limited to , resourceutilization groups (RUGs) for skilled nursing facilities, home health resource groups(HHRGs) for home health agencies, and case mix groups (CMGs) for inpatientrehabilitation facilities.

843 Advanced Billing Concepts (ABC) Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/WK, 1270/CAH

SOURCE

The CAM and Nursing Coding Manual

AVAILABLE FROM

Alternative Link

6121 Indian School Road NE

Suite 131

Albuquerque, NM 87110

ABSTRACT

The manual contains the Advanced Billing Concepts (ABC) codes,descriptive terms and identifiers for reporting complementary or alternative medicine,nursing, and other integrative health care procedures.

932 Universal Postal Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

116

SOURCE

Universal Postal Union website

AVAILABLE FROM

International Bureau of the Universal Postal Union

POST*CODE

Case postale 13

3000 BERNE 15 Switzerland

ABSTRACT

The postcode is the fundamental, essential element of an address. Aunique, universal identifier, it unambiguously identifies the addressee's locality andassists in the transmission and sorting of mail items. At present, 105 UPU membercountries use postcodes as part of their addressing systems.

Appendix B. Nomenclature

B.1 ASC X12 Nomenclature

B.1.1 Interchange and Application Control Structures

Appendix B is provided as a reference to the X12 syntax, usage, and relatedinformation. It is not a full statement of Interchange and Control Structure rules. Thefull X12 Interchange and Control Structures and other rules (X12.5, X12.6, X12.59, X12dictionaries, other X12 standards and official documents) apply unless specificallymodified in the detailed instructions of this implementation guide (see Section B.1.1.3.1.2 - Decimal for an example of such a modification).

B.1.1.1 Interchange Control Structure

The transmission of data proceeds according to very strict format rules to ensurethe integrity and maintain the efficiency of the interchange. Each business groupingof data is called a transaction set. For instance, a group of benefit enrollmentssent from a sponsor to a payer is considered a transaction set.

Each transaction set contains groups of logically related data in units calledsegments. For instance, the N4 segment used in the transaction set conveys the city,state, ZIP Code, and other geographic information. A transaction set containsmultiple segments, so the addresses of the different parties, for example, can beconveyed from one computer to the other. An analogy would be that the transactionset is like a freight train; the segments are like the train's cars; and eachsegment can contain several data elements the same as a train car can hold multiplecrates.

The sequence of the elements within one segment is specified by the ASC X12standard as well as the sequence of segments in the transaction set. In a moreconventional computing environment, the segments would be equivalent to records, andthe elements equivalent to fields.

Similar transaction sets, called "functional groups," can be sent together withina transmission. Each functional group is prefaced by a group start segment; and afunctional group is terminated by a group end segment. One or more functional groupsare prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control.

Figure B.1 - Transmission Control Schematic

Transmission Control Schematic

The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions:

  1. Define the data element separators and the data segment terminator.

  2. Identify the sender and receiver.

  3. Provide control information for the interchange.

  4. Allow for authorization and security information.

B.1.1.2 Application Control Structure Definitions and Concepts

B.1.1.2.1 Basic Structure

A data element corresponds to a data field in data processing terminology. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments.

B.1.1.2.2 Basic Character Set

The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here.

The basic character set of this standard, shown in Table B.1 - Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.

Table B.1 - Basic Character Set

A...Z 0...9 ! " & ' ( ) + *
, - . / : ; ? = ” (space)

B.1.1.2.3 Extended Character Set

An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in Table B.2 - Extended Character Set.

Table B.2 - Extended Character Set

a...z % ~ @ [ ] _ { }
\ | < > ^ ` # $

Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems.

For implementations compliant with this guide, either the entire extended character set must be acceptable, or the entire extended character set must not be used. In the absence of a specific trading partner agreement to the contrary, trading partners will assume that the extended character set is acceptable. Use of the extended character set allows the use of the "@" character in email addresses within the PER segment. Users should note that characters in the extended character set, as well as the basic character set, may be used as delimiters only when they do not occur in the data as stated in Section B.1.1.2.4.1 - Base Control Set.

B.1.1.2.4 Control Characters

Two control character groups are specified; they have restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In Table B.3 - Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5.

B.1.1.2.4.1 Base Control Set

The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by:

Table B.3 - Base Control Set

NOTATIONNAMEEBCDICASCIIIA5
BELbell2F0707
HThorizontal tab050909
LFline feed250A0A
VTvertical tab0B0B0B
FFform feed0C0C0C
CRcarriage return0D0D0D
FSfile separator1C1C1C
GSgroup separator1D1D1D
RSrecord separator1E1E1E
USunit separator1F1F1F
NL new line 15

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

B.1.1.2.4.2 Extended Control Set

The extended control set includes those that may have an effect on a transmission system. These are shown in Table B.4 - Extended Control Set.

Table B.4 - Extended Control Set

NOTATIONNAMEEBCDICASCIIIA5
SOHstart of header010101
STXstart of text020202
ETXend of text030303
EOTend of transmission370404
ENQenquiry2D0505
ACKacknowledge2E0606
DC1device control 1111111
DC2device control 2121212
DC3device control 3131313
DC4device control 43C1414
NAKnegative acknowledge3D1515
SYNsynchronous idle321616
ETBend of block261717
B.1.1.2.5 Delimiters

A delimiter is a character used to separate two data elements or component elements or to terminate a segment. The delimiters are an integral part of the data.

Delimiters are specified in the interchange header segment, ISA. The ISA segment can be considered in implementations compliant with this guide (see Appendix C, ISA Segment Note 1) to be a 105 byte fixed length record, followed by a segment terminator. The data element separator is byte number 4; the repetition separator is byte number 83; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator.

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in Table B.5 - Delimiters, in all examples of EDI transmissions.

Table B.5 - Delimiters

CHARACTERNAMEDELIMITER
*AsteriskData Element Separator
^CaratRepetition Separator
:ColonComponent Element Separator
~TildeSegment Terminator

The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element will result in errors in translation. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.

B.1.1.3 Business Transaction Structure Definitions and Concepts

The ASC X12 standards define commonly used business transactions (such as a healthcare claim) in a formal structure called "transaction sets." A transaction set iscomposed of a transaction set header control segment, one or more data segments, anda transaction set trailer control segment. Each segment is composed of thefollowing:

  • A unique segment ID

  • One or more logically related data elements each preceded by a data element separator

  • A segment terminator

B.1.1.3.1 Data Element

The data element is the smallest named unit of information in the ASC X12standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity.

Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained.

A simple data element within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated data element occurs.

Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements.

The data element types shown in Table B.6 - Data Element Types, appear in this implementation guide.

Table B.6 - Data Element Types

SYMBOLTYPE
NnNumeric
RDecimal
IDIdentifier
ANString
DTDate
TMTime
BBinary

The data element minimum and maximum lengths may be restricted in this implementation guide for a compliant implementation. Such restrictions may occur by virtue of the allowed qualifier for the data element or by specific instructions regarding length or format as stated in this implementation guide.

B.1.1.3.1.1 Numeric

A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data.

This set of guides denotes the number of implied decimal positions. The representation for this data element type is "Nn" where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point.

If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

EXAMPLE

A transmitted value of 1234, when specified as numeric type N2, represents a value of 12.34.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign.

B.1.1.3.1.2 Decimal

A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as "R."

The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point must be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point must be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point.

EXAMPLE

A transmitted value of 12.34 represents a decimal value of 12.34.

While the ASC X12 standard supports usage of exponential notation, this guide prohibits that usage.

For implementation of this guide under the rules promulgated under the Health Insurance Portability and Accountability Act (HIPAA), decimal data elements in Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note the statement in the preceding paragraph that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

For implementations mandated under HIPAA rules:

  • The following transmitted value represents the largest positive dollar amount that can be sent: 99999999.99

  • The following transmitted value is the longest string of characters that can be sent representing whole dollars: 99999999

  • The following transmitted value is the longest string of characters that can be sent representing negative dollars and cents: -99999999.99

  • The following transmitted value is the longest string of characters that can be sent representing negative whole dollars: -99999999

B.1.1.3.1.3 Identifier

An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by the Committee. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is "ID."

B.1.1.3.1.4 String

A string data element is a sequence of any characters from the basic or extended character sets. The string data element must contain at least one non-space character. The significant characters shall be left justified. Leading spaces, when they occur, are presumed to be significant characters. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. The representation for this data element type is"AN."

B.1.1.3.1.5 Date

A date data element is used to express the standard date in either YYMMDD or CCYYMMDD format in which CC is the first two digits of the calendar year, YY is the last two digits of the calendar year, MM is the month (01 to 12), and DD is the day in the month (01 to 31). The representation for this data element type is "DT." Users of this guide should note that all dates within transactions are 8-character dates (millennium compliant) in the format CCYYMMDD. The only date data element that is in format YYMMDD is the Interchange Date data element in the ISA segment and the TA1 segment where the century is easily determined because of the nature of an interchange header.

B.1.1.3.1.6 Time

A time data element is used to express the ISO standard time HHMMSSd..d format in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is decimal seconds. The representation for this data element type is "TM." The length of the data element determines the format of the transmitted time.

EXAMPLE

Transmitted data elements of four characters denote HHMM. Transmitted data elements of six characters denote HHMMSS.

B.1.1.3.1.7 Binary

The binary data element is any sequence of octets ranging in value from binary 00000000 to binary 11111111. This data element type has no defined maximum length. Actual length is specified by the immediately preceding data element. Within the body of a transaction set (from ST to SE) implemented according to this technical report, the binary data element type is only used in the segments Binary Data Segment BIN, and Binary Data Structure BDS. Within those segments, Data Element 785 Binary Data is a string of octets which can assume any binary pattern from hexadecimal 00 to FF, and can be used to send text as well as coded data, including data from another application in its native format. The binary data type is also used in some control and security structures.

Not all transaction sets use the Binary Data Segment BIN or Binary Data Structure BDS.

B.1.1.3.2 Repeating Data Elements

Simple or composite data elements within a segment can be designated asrepeating data elements. Repeating data elements are adjacent data elements thatoccur up to a number of times specified in the standard as number of repeats.The implementation guide may also specify the number of repeats of a repeatingdata element in a specific location in the transaction that are permitted in acompliant implementation. Adjacent occurrences of the same repeating simple dataelement or composite data structure in a segment shall be separated by arepetition separator.

B.1.1.3.3 Composite Data Structure

The composite data structure is an intermediate unit of information in asegment. Composite data structures are composed of one or more logically relatedsimple data elements, each, except the last, followed by a sub-elementseparator. The final data element is followed by the next data element separatoror the segment terminator. Each simple data element within a composite is calleda component.

Each composite data structure has a unique four-character identifier, a name, and a purpose. The identifier serves as a label for the composite. A composite data structure can be further defined through the use of syntax notes, semantic notes, and comments. Each component within the composite is further characterized by a reference designator and a condition designator. The reference designators and the condition designators are described in Section B.1.1.3.8 - Reference Designator and Section B.1.1.3.9 - Condition Designator.

A composite data structure within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated composite data structure occurs.

B.1.1.3.4 Data Segment

The data segment is an intermediate unit of information in a transaction set.In the data stream, a data segment consists of a segment identifier, one or morecomposite data structures or simple data elements each preceded by a dataelement separator and succeeded by a segment terminator.

Each data segment has a unique two- or three-character identifier, a name, anda purpose. The identifier serves as a label for the data segment. A segment canbe further defined through the use of syntax notes, semantic notes, andcomments. Each simple data element or composite data structure within thesegment is further characterized by a reference designator and a conditiondesignator.

B.1.1.3.5 Syntax Notes

Syntax notes describe relational conditions among two or more data segment units within the same segment, or among two or more component data elements within the same composite data structure. For a complete description of the relational conditions, See Section B.1.1.3.9 - Condition Designator.

B.1.1.3.6 Semantic Notes

Simple data elements or composite data structures may be referenced by a semantic note within a particular segment. A semantic note provides important additional information regarding the intended meaning of a designated data element, particularly a generic type, in the context of its use within a specific data segment. Semantic notes may also define a relational condition among data elements in a segment based on the presence of a specific value (or one of a set of values) in one of the data elements.

B.1.1.3.7 Comments

A segment comment provides additional information regarding the intended use of the segment.

B.1.1.3.8 Reference Designator

Each simple data element or composite data structure in a segment is provideda structured code that indicates the segment in which it is used and thesequential position within the segment. The code is composed of the segmentidentifier followed by a two-digit number that defines the position of thesimple data element or composite data structure in that segment.

For purposes of creating reference designators, the composite data structureis viewed as the hierarchical equal of the simple data element. Each componentdata element in a composite data structure is identified by a suffix appended tothe reference designator for the composite data structure of which it is amember. This suffix is prefixed with a hyphen and definesthe position of the component data element in the composite data structure.

EXAMPLE

  • The first simple element of the CLP segment would be identified as CLP01.

  • The first position in the SVC segment is occupied by a composite data structure that contains seven component data elements, the reference designator for the second component data element would be SVC01-02.

B.1.1.3.9 Condition Designator

This section provides information about X12 standard conditions designators. It is provided so that users will have information about the general standard. Implementation guides may impose other conditions designators. See implementation guide section 2.1 Presentation Examples for detailed information about the implementation guide Industry Usage requirements for compliant implementation.

Data element conditions are of three types: mandatory, optional, and relational. They define the circumstances under which a data element may be required to be present or not present in a particular segment.

Table B.7 - Condition Designator

DESIGNATOR DESCRIPTION
M- Mandatory The designation of mandatory is absolute in the sense that there is no dependency on other data elements. This designation may apply to either simple data elements or composite data structures. If the designation applies to a composite data structure, then at least one value of a component data element in that composite data structure shall be included in the data segment.
O- OptionalThe designation of optional means that there is no requirement for a simple data element or composite data structure to be present in the segment. The presence of a value for a simple data element or the presence of value for any of the component data elements of a composite data structure is at the option of the sender.
X- RelationalRelational conditions may exist among two or more simple data elements within the same data segment based on the presence or absence of one of those data elements (presence means a data element must not be empty). Relational conditions are specified by a condition code (see table below) and the reference designators of the affected data elements. A data element may be subject to more than one relational condition.
The definitions for each of the condition codes used within syntax notes are detailed below:
CONDITION CODEDEFINITION
P- Paired or Multiple If any element specified in the relational condition is present, then all of the elements specified must be present.
R- RequiredAt least one of the elements specified in the condition must be present.
E- Exclusion Not more than one of the elements specified in the condition may be present.
C- ConditionalIf the first element specified in the condition is present, then all other elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.
L- List Conditional If the first element specified in the condition is present, then at least one of the remaining elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.
B.1.1.3.10 Absence of Data

Any simple data element that is indicated as mandatory must not be empty if the segment is used. At least one component data element of a composite data structure that is indicated as mandatory must not be empty if the segment is used. Optional simple data elements and/or composite data structures and their preceding data element separators that are not needed must be omitted if they occur at the end of a segment. If they do not occur at the end of the segment, the simple data element values and/or composite data structure values may be omitted. Their absence is indicated by the occurrence of their preceding data element separators, in order to maintain the element's or structure's position as defined in the data segment.

Likewise, when additional information is not necessary within a composite, the composite may be terminated by providing the appropriate data element separator or segment terminator.

If a segment has no data in any data element within the segment (an "empty" segment), that segment must not be sent.

B.1.1.3.11 Control Segments

A control segment has the same structure as a data segment, but it is used fortransferring control information rather than application information.

B.1.1.3.11.1 Loop Control Segments

Loop control segments are used only to delineate bounded loops. Delineation of the loop shall consist of the loop header (LS segment) and the loop trailer (LE segment). The loop header defines the start of a structure that must contain one or more iterations of a loop of data segments and provides the loop identifier for this loop. The loop trailer defines the end of the structure. The LS segment appears only before the first occurrence of the loop, and the LE segment appears only after the last occurrence of the loop. Unbounded looping structures do not use loop control segments.

B.1.1.3.11.2 Transaction Set Control Segments

The transaction set is delineated by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifier of the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments.

B.1.1.3.11.3 Functional Group Control Segments

The functional group is delineated by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number and application identification information. The functional group trailer defines the end of the functional group of related transaction sets and provides a count of contained transaction sets.

B.1.1.3.11.4 Relations among Control Segments

The control segment of this standard must have a nested relationship as is shown and annotated in this subsection. The letters preceding the control segment name are the segment identifier for that control segment. The indentation of segment identifiers shown below indicates the subordination among control segments.

GS Functional Group Header, starts a group of related transaction sets.

ST Transaction Set Header, starts a transaction set.

LS Loop Header, starts a bounded loop of data segments but is not part of the loop.

LS Loop Header, starts an inner, nested, bounded loop.

LE Loop Trailer, ends an inner, nested bounded loop.

LE Loop Trailer, ends a bounded loop of data segments but is not part of the loop.

SE Transaction Set Trailer, ends a transaction set.

GE Functional Group Trailer, ends a group of related transaction sets.

More than one ST/SE pair, each representing a transaction set, may be used within one functional group. Also more than one LS/LE pair, each representing a bounded loop, may be used within one transaction set.

B.1.1.3.12 Transaction Set

The transaction set is the smallest meaningful set of information exchangedbetween trading partners. The transaction set consists of a transaction setheader segment, one or more data segments in a specified order, and atransaction set trailer segment. See Figure B.1 - Transmission Control Schematic.

B.1.1.3.12.1 Transaction Set Header and Trailer

A transaction set identifier uniquely identifies a transaction set. This identifier is the first data element of the Transaction Set Header Segment (ST). A user assigned transaction set control number in the header must match the control number in the Trailer Segment (SE) for any given transaction set. The value for the number of included segments in the SE segment is the total number of segments in the transaction set, including the ST and SE segments.

B.1.1.3.12.2 Data Segment Groups

The data segments in a transaction set may be repeated as individual data segments or as unbounded or bounded loops.

B.1.1.3.12.3 Repeated Occurrences of Single Data Segments

When a single data segment is allowed to be repeated, it may have a specified maximum number of occurrences defined at each specified position within a given transaction set standard. Alternatively, a segment may be allowed to repeat an unlimited number of times. The notation for an unlimited number of repetitions is ">1."

B.1.1.3.12.4 Loops of Data Segments

Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded.

Unbounded Loops

To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. Alternatively, the loop may be specified as having an unlimited number of iterations. The notation for an unlimited number of repetitions is ">1."

A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines an occurrence of the loop.

The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs.

Bounded Loops

The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require a Loop Start Segment (LS) to appear before the first occurrence and a Loop End Segment (LE) to appear after the last consecutive occurrence of the loop. If the loop does not occur, the LS and LE segments are uppressed.

B.1.1.3.12.5 Data Segments in a Transaction Set

When data segments are combined to form a transaction set, three characteristics are applied to each data segment: a requirement designator, a position in the transaction set, and a maximum occurrence.

B.1.1.3.12.6 Data Segment Requirement Designators

A data segment, or loop, has one of the following requirement designators for health care and insurance transaction sets, indicating its appearance in the data stream of a transmission. These requirement designators are represented by a single character code.

Table B.8 - Data Segment Requirement Designators

DESIGNATORDESCRIPTION
M- MandatoryThis data segment must be included in the transaction set. (Note that a data segment may be mandatory in a loop of data segments, but the loop itself is optional if the beginning segment of the loop is designated as optional.)
O- OptionalThe presence of this data segment is the option of the sending party.
B.1.1.3.12.7 Data Segment Position

The ordinal positions of the segments in a transaction set are explicitly specified for that transaction. Subject to the flexibility provided by the optional requirement designators of the segments, this positioning must be maintained.

B.1.1.3.12.8 Data Segment Occurrence

A data segment may have a maximum occurrence of one, a finite number greater than one, or an unlimited number indicated by ">1."

B.1.1.3.13 Functional Group

A functional group is a group of similar transaction sets that is bounded by afunctional group header segment and a functional group trailer segment. Thefunctional identifier defines the group of transactions that may be includedwithin the functional group. The value for the functional group control numberin the header and trailer control segments must be identical for any givengroup. The value for the number of included transaction sets is the total numberof transaction sets in the group. See Figure B.1 - Transmission Control Schematic.

B.1.1.4 Envelopes and Control Structures

B.1.1.4.1 Interchange Control Structures

Typically, the term "interchange" connotes the ISA/IEA envelope that istransmitted between trading/business partners. Interchange control is achievedthrough several "control" components. The interchange control number iscontained in data element ISA13 of the ISA segment. The identical control numbermust also occur in data element 02 of the IEA segment. Most commercialtranslation software products will verify that these two elements are identical.In most translation software products, if these elements are different theinterchange will be "suspended" in error.

There are many other features of the ISA segment that are used for controlmeasures. For instance, the ISA segment contains data elements such asauthorization information, security information, sender identification, andreceiver identification that can be used for control purposes. These dataelements are agreed upon by the trading partners prior to transmission. Theinterchange date and time data elements as well as the interchange controlnumber within the ISA segment are used for debugging purposes when there is aproblem with the transmission or the interchange.

Data Element ISA12, Interchange Control Version Number, indicates the versionof the ISA/IEA envelope. GS08 indicates the version of the transaction setscontained within the ISA/IEA envelope. The versions are not required to be thesame. An Interchange Acknowledgment can be requested through data element ISA14.The interchange acknowlegement is the TA1 segment. Data element ISA15, TestIndicator, is used between trading partners to indicate that the transmission isin a "test" or "production" mode. Data element ISA16, Subelement Separator, isused by the translator for interpretation of composite data elements.

The ending component of the interchange or ISA/IEA envelope is the IEAsegment. Data element IEA01 indicates the number of functional groups that areincluded within the interchange. In most commercial translation softwareproducts, an aggregate count of functional groups is kept while interpreting theinterchange. This count is then verified with data element IEA01. If there is adiscrepancy, in most commercial products, the interchange is suspended. Theother data element in the IEA segment is IEA02 which is referenced above.

See Appendix C, EDI Control Directory, for a complete detailing of theinter-change control header and trailer. The authors recommend that when twotransactions with different X12 versions numbers are sent in one interchangecontrol structure (multiple functional groups within one ISA/IEA envelope), theInterchange Control version used should be that of the most recent transactionversion included in the envelope. For the transmission of HIPAA transactionswith mixed versions, this would be a compliant enveloping structure.

B.1.1.4.2 Functional Groups

Control structures within the functional group envelope include the functionalidentifier code in GS01. The Functional Identifier Code is used by thecommercial translation software during interpretation of the interchange todetermine the different transaction sets that may be included within thefunctional group. If an inappropriate transaction set is contained within thefunctional group, most commercial translation software will suspend thefunctional group within the interchange. The Application Sender's Code in GS02can be used to identify the sending unit of the transmission. The ApplicationReceiver's Code in GS03 can be used to identify the receiving unit of thetransmission. The functional group contains a creation date (GS04) and creationtime (GS05) for the functional group. The Group Control Number is contained inGS06. These data elements (GS04, GS05, and GS06) can be used for debuggingpurposes. GS08,Version/Release/Industry Identifier Code is theversion/release/sub-release of the transaction sets being transmitted in thisfunctional group.

The Functional Group Control Number in GS06 must be identical to data element02 of the GE segment. Data element GE01 indicates the number of transaction setswithin the functional group. In most commercial translation software products,an aggregate count of the transaction sets is kept while interpreting thefunctional group. This count is then verified with data element GE01.

See Appendix C, EDI Control Directory, for a complete detailing of thefunctional group header and trailer.

B.1.1.4.3 HL Structures

The HL segment is used in several X12 transaction sets to identify levels ofdetail information using a hierarchical structure, such as relating dependentsto a subscriber. Hierarchical levels may differ from guide to guide.

For example, each provider can bill for one or more subscribers, eachsubscriber can have one or more dependents and the subscriber and the dependentscan make one or more claims.

Each guide states what levels are available, the level's usage, number ofrepeats, and whether that level has subordinate levels within a transaction set.

For implementations compliant with this guide, the repeats of the loopsidentified by the HL structure shall appear in the hierarchical order specifiedin BHT01, when those particular hierarchical levels exist. That is, an HL parentloop must be followed by the subordinate child loops, if any, prior tocommencing a new HL parent loop at the same hierarchical level.

The following diagram, from transaction set 837, illustrates a typicalhierarchy.

The two examples below illustrate this requirement:

Example 1 based on Implementation Guide 811X201:

INSURER

First STATE in transaction (child of INSURER)

First POLICY in transaction (child of first STATE)

First VEHICLE in transaction (child of first POLICY)

Second POLICY in transaction (child of first STATE)

Second VEHICLE in transaction (child of second POLICY)

Third VEHICLE in transaction (child of second POLICY)

Second STATE in transaction (child of INSURER)

Third POLICY in transaction (child of second STATE)

Fourth VEHICLE in transaction (child of third POLICY)

Example 2 based on Implementation Guide 837X141

First PROVIDER in transaction

First SUBSCRIBER in transaction (child of first PROVIDER)

Second PROVIDER in transaction

Second SUBSCRIBER in transaction (child of second PROVIDER)

First DEPENDENT in transaction (child of second SUBSCRIBER)

Second DEPENDENT in transaction (child of second SUBSCRIBER)

Third SUBSCRIBER in transaction (child of second PROVIDER)

Third PROVIDER in transaction

Fourth SUBSCRIBER in transaction (child of third PROVIDER)

Fifth SUBSCRIBER in transaction (child of third PROVIDER)

Third DEPENDENT in transaction (child of fifth SUBSCRIBER)

B.1.1.5 Acknowledgments

B.1.1.5.1 Interchange Acknowledgment, TA1

The TA1 segment provides the capability for the interchange receiver to notify the sender that a valid envelope was received or that problems were encountered with the interchange control structure. The TA1 verifies the envelopes only. Transaction set-specific verification is accomplished through use of the Functional Acknowledgment Transaction Set, 997. See Section B.1.1.5.2 - Functional Acknowledgment, 997, for more details. The TA1 is unique in that it is a single segment transmitted without the GS/GE envelope structure. A TA1 can be included in an interchange with other functional groups and transactions.

Encompassed in the TA1 are the interchange control number, interchange date and time, interchange acknowledgment code, and the interchange note code. The interchange control number, interchange date and time are identical to those that were present in the transmitted interchange from the trading partner. This provides the capability to associate the TA1 with the transmitted interchange. TA104, Interchange Acknowledgment Code, indicates the status of the interchange control structure. This data element stipulates whether the transmitted interchange was accepted with no errors, accepted with errors, or rejected because of errors. TA105, Interchange Note Code, is a numerical code that indicates the error found while processing the interchange control structure. Values for this data element indicate whether the error occurred at the interchange or functional group envelope.

B.1.1.5.2 Functional Acknowledgment, 997

The Functional Acknowledgment Transaction Set, 997, has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgment process facilitates control of EDI. There is a one-to-one correspondence between a 997 and a functional group. Segments within the 997 can identify the acceptance or rejection of the functional group, transaction sets or segments. Data elements in error can also be identified. There are many EDI implementations that have incorporated the acknowledgment process in all of their electronic communications. The 997 is used as a functional acknowledgment to a previously transmitted functional group.

The 997 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission.

B.2 Object Descriptors

Object Descriptors (OD) provide a method to uniquely identify specific locations within animplementation guide. There is an OD assigned at every level of the X12N implementation:

  1. Transaction Set

  2. Loop

  3. Segment

  4. Composite Data Element

  5. Component Data Element

  6. Simple Data Element

ODs at the first four levels are coded using X12 identifiers separated by underbars:

EntityExample
1. Transaction Set Identifier plus a unique 2 character value837Q1
2. Above plus under bar plus Loop Identifier as assigned within an implementation guide837Q1_2330C
3. Above plus under bar plus Segment Identifier837Q1_2330C_NM1
4. Above plus Reference Designator plus under bar plus Composite Identifier837Q1_2400_SV101_C003

The fifth and sixth levels add a name derived from the "Industry Term" defined in the X12NData Dictionary. The name is derived by removing the spaces.

EntityExample
5. Number 4 above plus composite sequence plus under bar plus name837Q1_2400_SV101_C00302_ProcedureCode
6. Number 3 above plus Reference Designator plus two under bars plus name837Q1_2330C_NM109__OtherPayerPatientPrimaryIdentifier

Said in another way, ODs contain a coded component specifying a location in animplementation guide, a separator, and a name portion. For example:

Since ODs are unique across all X12N implementation guides, they can be used for a varietyof purposes. For example, as a cross reference to older data transmission systems, like theNational Standard Format for health care claims, or to form XML tags for newer datatransmission systems.

Appendix D. Change Summary

D.1 Change Summary

This is the ASC X12 version 5010 implementation guide for the 835. The following substantive changes have occurred since the previous ASC X12N guide, which was based upon Version 4050 of the 835:

  1. Situational notes throughout have been moved into the new Situational Rule headings and formatted to comply with ASC X12N implementation guide standards.

  2. Section 1.1, Implementation Purpose and Scope, revised version of TR3.

  3. Section 1.3, Implementation Limitations, has been revised.

  4. Section 1.4.1, Informational Flows, revised Figure 1.1 to add a 'start' point.

  5. Reversed order of paragraphs in Section 1.6.1, 1.6.2, 1.6.3 and added verbiage to indicate the usage of these transactions in relationship to the 835.

  6. Section 1.10.2.5, Advance Payments and Reconciliation, has been revised. Also revised last sentence in Note.

  7. Section 1.10.2.8, Reversals and Corrections, has been revised to clarify the author's intended meaning. Also, has been expanded to include information about the usage of the claim level AMT segment with reversals, including specific instructions for when interest or prompt payment discounts are involved. Under third Note, revised bullet 3 to bold the word 'reversal' and split bullet 3 into 2 separate bullets. The use of CAS Group Code 'CR' has been removed from processing with the 835 transaction.

  8. Section 1.10.2.9, Interest and Prompt Payment Discounts, has been revised to clarify information about usage with reversal claims. The third bullet under Summary was revised to remove 'PLB03'.

  9. Section 1.10.2.13, Secondary Payment Reporting Considerations, has been rewritten.

  10. Section 1.10.2.19, Reporting Encounters in the 835, has been rewritten.

  11. Section 2.2.1 was replaced with text from the new common content.

  12. Section 2.2.2 new section inserted to include the new common content.

  13. Section 2.2.3 was previous section 2.2.2 and revised to include the new common content.

  14. PER, Payer Web Site, Added a new iteration of the Payer Contact PER segment in loop 1000A to identify the Payer URL.

  15. CLP - Claim Payment Information, CLP02 - added an element note and revised all notes under codes 1, 2, 3, 4.

  16. REF, Healthcare Policy Identification, revised entire segment.

  17. Section 3.3, Business Scenario, entire section has been revised.

D.2 Change Detail

Situational notes throughout have been moved into the new Situational Rule headings and formatted to comply with ASC X12N implementation guide standards.

Section 1.1, Implementation Purpose and Scope, revised version of TR3.

Section 1.3, Implementation Limitations, has been revised.

Section 1.3.2 revised the statement on the size limit of the 835 transaction.

Section 1.4.1, Informational Flows, revised Figure 1.1 to add a 'start' point.

Section 1.5, Business Terminology, added introductory paragraph and definitions of terms.

Section 1.6, Transaction Acknowledgments, Added introductory paragraph and revised spelling of 'acknowledgment', deleted last sentence of paragraph 2 and removed words 'beyond syntax' from paragraph 3.

Reversed order of paragraphs in Section 1.6.1, 1.6.2, 1.6.3 and added verbiage to indicate the usage of these transactions in relationship to the 835.

Section 1.7.1, Data Relationships with Other transactions, removed last sentence of paragraph 3. Added reference to NCPDP segment.

Replaced Section 1.8 with new common context text.

Section 1.10.2, Data Use by Business Use, added PLB segment name.

Section 1.10.2.1.1, Service Line Balancing, moved Figure 1.9 to below this section and added word "plus or".

Section 1.10.2.4, Claim Adjustment and Service Adjustment Segment Theory, paragraph 7 added new last sentence and a note.

Section 1.10.2.5, Advance Payments and Reconciliation, has been revised. Also revised last sentence in Note.

Section 1.10.2.6, Procedure Code Bundling and Unbundling, added last sentence to second Note. Revised CAS segment in last example.

Section 1.10.2.8, Reversals and Corrections, has been revised to clarify the author's intended meaning. Also, has been expanded to include information about the usage of the claim level AMT segment with reversals, including specific instructions for when interest or prompt payment discounts are involved.

Under third Note, revised bullet 3 to bold the word 'reversal' and split bullet 3 into 2 separate bullets.

The use of CAS Group Code 'CR' has been removed from processing with the 835 transaction.

Section 1.10.2.9, Interest and Prompt Payment Discounts, has been revised to clarify information about usage with reversal claims. The third bullet under Summary was revised to remove 'PLB03'.

Section 1.10.2.11, Claim Splitting, revised word position to loop in third paragraph.

Section 1.10.2.12, Balance Forward Processing, revised second PLB segment example for PLB01 and added a new sentence under NOTE.

Section 1.10.2.13, Secondary Payment Reporting Considerations, has been rewritten.

Section 1.10.2.14.1, Service Line Splitting, last CLP segment example was revised for CLP03.

Section 1.10.2.17, Claim Overpayment Recovery, added 2 new ending sentences to paragraph 4.

Section 1.10.2.19, Reporting Encounters in the 835, has been rewritten.

Section 2.2.1 was replaced with text from the new common content.

Section 2.2.2 new section inserted to include the new common content.

Section 2.2.3 was previous section 2.2.2 and revised to include the new common content.

BPR, Financial Information, TR3 example has been corrected.

BPR02 element note was revised for the 9's in parentheses and an additional sentence was added to the note.

BPR04 codes BOP and FWT have had clarifying notes added.

BPR 11, TRN02 and TRN04 have had a clarifying notes added.

BPR03, the term NOT ADVISED was removed and the note updated.

TRN, Reassociation Trace Number.

TRN03 - added 'TIN'.

CUR, Foreign Currency information.

CUR03 - exchange rate has been changed from Situational to Not Used.

N1, Payer Identification.

N102 - made element required.

REF - Additional Payer Identification, Revised TR3 note 1.

REF01 - removed term ADVISED under code NF and added note. Revised note under code EO.

PER, Payer Contact Information, revised TR3 example.

PER05 - revised note under code EX.

PER07 - revised note under code EX.

PER, Payer Contact Information, revised TR3 Note 1 and example.

PER Payer Technical Contact Information. Added a new iteration of the Payer Contact PER Segment in loop 1000A to identify the Payer's technical contact.

PER, Payer Web Site, Added a new iteration of the Payer Contact PER segment in loop 1000A to identify the Payer URL.

N1 - Payee Identification, Revised TR3 example.

N103 - revised notes for codes FI, XX.

REF, Payee Additional Identification.

REF01 - revised noted for code TJ.

RDM, Remittance Delivery Method, revised Situational Rule. Added segment??

LX, Header Number, revised situational Rule and TR3 Note 1.

TS3, Provider Summary Information, added second note under element and revised all references to "Segment Note 2" to "TR3 Note 3".

TS305 - added element note.

TS2, Provider Supplemental Summary Information, revised all references to "segment note 2' to "TR3 note 2".

CLP - Claim Payment Information, revised TR3 note 1.

CLP01 - revised element note.

CLP02 - added an element note and revised all notes under codes 1, 2, 3, 4.

CLP03 - added sentence to element note.

CLP05 - removed words 'and corrections'.

CLP06 - revised note 1 references to TRN03 or BPR10 and added new codes 17, ZZ.

CAS - Claim Adjustment, revised TR3 note 2 and 3 and TR3 example revised.

CAS01 - changed note under code CR.

CAS02 - added element note.

CAS03 -added note defining element format in line with decimals.

NM1, Patient Name, revised TR3 note 2.

NM103 and NM104 have been changed from Required to Situational.

NM1, Insured Name, revised TR3 Note 2 and TR3 example.

NM108 - removed term ADVISED.

NM1, Service Provider Name.

NM108 - removed term ADVISED on code FI and XX and added note under codes.

NM104, NM105, NM107 - changed element note.

NM1, Crossover Carrier Name.

NM108 - removed term ADVISED on code NI and XV and added note under codes.

NM1, Corrected Priority Payer Name.

NM108 - removed term ADVISED on code NI and XV and added note under codes.

NM1, Other Subscriber Name.

NM104, NM105, NM107 - changed note.

NM108 - deleted code 34, revised note for MI.

MIA, Inpatient Adjudication Information.

MIA02 - revised element note.

MOA, Outpatient Adjudication Information, added TR3 note 2.

MOA02 - revised element note.

REF, Rendering Provider identification.

REF02 - added codes LU, OB, 1J.

DTM, Covered Expiration Date, revised Situational Rule.

DTM, Claim Received Date, revised Situational Rule.

PER, Claim Contact Information, changed TR3 note 1.

AMT, Claim Supplemental Information.

AMT02 - added element note.

SVC, Service Payment Information, changed Situational Rule and TR3 note 2.

SVC01-1 - changed notes and added code ER.

SVC01-7 - is changed to NOT USED.

SVC02 - added element note.

SVC05 - revised situational rule.

SVC06-1 - changed notes and added code ER, revised note on code WK.

DTM, Service Date, revised situational rule.

DTM01 - revised notes on all qualifiers.

CAS, Service Adjustment, revised TR3 Note 2 and TR3 example.

CAS01 - revised notes associated with Group Codes CR, OA, PI.

CAS02 - added element note.

CAS03 - added additional element note.

REF, Line Item Control Number. REF01 Qualifier 6R (Provider Control Number) has been moved to be a separate, dedicated iteration of the REF segment.

REF, Rendering Provider Information, revised TR3 example.

REF01 - removed term ADVISED on code SY and TJ, added code D3, changed note on HPI.

Added code G2, D3.

REF, Healthcare Policy Identification, revised entire segment.

AMT, Service Supplemental Amount.

AMT01 - added note under code B6.

AMT02 - added element note.

PLB, Provider Adjustment, change TR3 note 1.

PLB01 - changed element note.

PLB03-1 - revised note under code WU, AP, FB.

PLB04 - added element note 2.

Section 3.1.2, Transmission, revised example.

Section 3.3, Business Scenario, entire section has been revised.

Section B.1.1.2.3, Extended Character Set, fixed reference to Section B.1.1.2.5.

Section B.1.1.2.5, delimiters, revised reference to TR3 Note.

Section B.1.1.4.1, Interchange Control Structures, revised last sentence in paragraph 1 and 4.

Section B.1.1.5.1, Interchange Acknowledgment, TA1, revised section from new common content.

GS, Functional Group Header, revised TR3 example.

GS01, GS08 - removed second note.

Appendix A, External Code Source, added introductory paragraph.

D.3 Errata Changes

Errata changes appear in yellow highlight. Listed below are the specific changes, their page number location in the original guide, and a link to the change in this document.

Section 1.2 - Version Information

Original page 1, paragraph 2

Table 1 - Header Detail

Original page 62, Segment Usage, Loop 1000B, N4 Segment changes to Situational ("S")

BPR - FINANCIAL INFORMATION

Original page 71, Header Section, BPR Segment, BPR02 Data Element note

N1 - PAYER IDENTIFICATION

Original page 88, Header Section, Loop 1000A, N1 Segment, N103 & N104 Data Elements Change Situational Rules, N103 Data Element - Code XV Change Note

REF - ADDITIONAL PAYER IDENTIFICATION

Original page 92, Header Section, Loop 1000A, REF Segment, Change Situational Rule

PER - PAYER WEB SITE

Original page 100, Header Section, Loop 1000A PER Segment, Situational Rule and TR3 note

N1 - PAYEE IDENTIFICATION

Original page 103, Header Section, Loop 1000B, N1 Segment, N103 Data Element - Code XV Change Note

N4 - PAYEE CITY, STATE, ZIP CODE

Original page 105, Header Section, Loop 1000B N4 Segment, Change Requirement and add Situational Rule

REF - PAYEE ADDITIONAL IDENTIFICATION

Original page 107, Header Section, Loop 1000B, REF01 Data Element, Code TJ, Change Note

NM1 - PATIENT NAME

Original page 137, Detail Section, Loop 2100 NM1 Segment, TR3 notes

NM1 - INSURED NAME

Original page 140, Detail Section, Loop 2100 NM1 Segment, Situational Rule and TR3 note

NM1 - CROSSOVER CARRIER NAME

Original page 151, Detail Section, Loop 2100 NM1 Segment, NM108 Data Element, Codes NI & XV - Change Notes

NM1 - CORRECTED PRIORITY PAYER NAME

Original page 154, Detail Section, Loop 2100 NM1 Segment, NM108 Data Element, Codes NI & XV - Change Notes

REF - HEALTHCARE POLICY IDENTIFICATION

Original page 209, Detail Section, Loop 2110 REF Segment, Situational Rule

GS - FUNCTIONAL GROUP HEADER

Original page C.7, GS Segment example

GS08 - Version / Release / Industry Identifier Code

Original page C.8, GS08 Data Element, Code 005010X221