835 Transaction Set Listing

008020X322 Health Care Claim Payment/Advice
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. 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.
  2. The first element separator defines the element separator to be used through the entire interchange.
  3. Spaces in the example interchanges are represented by "." for clarity.
  4. The ISA segment terminator defines the segment terminator used throughout the entire interchange.
  5. All positions within each of the data elements must be filled.
TR3 Example:
ISA✱00✱..........✱01✱SECRET....✱ZZ✱SENDERS.ID.....✱ZZ✱RECEIVERS.ID...✱030101✱1253✱^✱00802✱000000905✱0✱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)
CODE SOURCE: 121: Health Industry Number
27
Carrier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
28
Fiscal Intermediary Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
29
Medicare Provider and Supplier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
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)
CODE SOURCE: 121: Health Industry Number
27
Carrier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
28
Fiscal Intermediary Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
29
Medicare Provider and Supplier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
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 Code
M 1
ID
5
Code specifying the version number of the interchange control segments, the version of the data elements within the control segments, and the code values within those data elements.
INDUSTRY NAME: Interchange Control Version Number
CODE
DEFINITION
00802
00802 Standards Approved for Publication by ASC X12 Procedures Review Board through December 2020
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 Code
M 1
ID
1
Code indicating sender's request for an interchange acknowledgment
INDUSTRY NAME: Acknowledgment Requested
X12.5 - Interchange Control Structure provides the purpose of the TA1 segment. The X12 Acknowledgment Reference Model provides considerable information about the TA1 segment.
CODE
DEFINITION
0
No Interchange Acknowledgment Requested
Use when the interchange contains ONLY acknowledgment Functional Groups (e.g. 999 or 824) or a TA1.
1
Interchange Acknowledgment Requested (TA1)
Use when batch process requires the return of a TA1 for the interchange.
2
Interchange Acknowledgment Requested only when Interchange is "Rejected Because Of Errors"
Use when the transaction is for real-time processing.
3
Interchange Acknowledgment Requested only when Interchange is "Rejected Because Of Errors" or "Accepted but Errors are Noted"
Use when batch processing requires the return of a TA1 for the interchange only when errors are noted.
Required
15
I14
Interchange Usage Indicator Code
M 1
ID
1
Code indicating whether data enclosed by this interchange envelope is test, production or information
INDUSTRY NAME: Interchange Usage Indicator
CODE
DEFINITION
I
Information
Use when the interchange contains ONLY a TA1.
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✱RECEIVER CODE✱19991231✱0802✱1✱X✱008020X322~
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
008020X322
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✱0002✱008020X322~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code 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).
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 and must be a numeric value. The number (i.e. numeric value) is assigned by the originator and must be unique within a functional group (GS-GE). For example, start with the numeric value 0001 and increment from there. The Transaction Set Control Number also aids in error resolution research.
Required
3
1705
Implementation Convention Reference
O 1
AN
1/35
Reference assigned to identify Implementation Convention
SEMANTIC: The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08.
INDUSTRY NAME: Implementation Guide Version Name
  1. This element must be populated with the guide identifier named in Section 1.2.
  2. This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is used at translation time.
CODE
DEFINITION
008020X322
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✱I✱150000✱C✱ACH✱CCP✱01✱999999992✱DA✱123456✱1512345678✱999999999✱01✱999988880✱DA✱98765✱20190901~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
305
Transaction Handling Code
M 1
ID
1/2
Code specifying the action to be taken by all parties
CODE
DEFINITION
C
Payment Accompanies Remittance Advice
Use when the third party processor will move both funds and remittance detail together through the banking system.
D
Make Payment Only
Use when the third party processor will move only funds through the banking system and ignore any remittance information.
H
Notification Only
Use when the actual provider payment (BPR02) is zero and the transaction is not being used for Pre-notification of Future Transfers. This indicates remittance information without any associated payment.
I
Remittance Information Only
Use when the remittance detail is moving separately from the payment.
K
Reimbursement to Follow
Use when this 835 is a real-time response to a real-time 837.
P
Prenotification of Future Transfers
Use when the payer and the banking system are initially validating account numbers before beginning an EFT relationship. Contact your VAB for additional information.
U
Split Payment and Remittance
Use when a third party processor will split the payment and remittance detail and send each on a separate path.
X
Handling Party's Option to Split Payment and Remittance
Use when the third party processor will 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. Although the value can be zero, the 835 cannot be issued for less than zero dollars.
  2. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 when indicating 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. For card payments, use this code for Straight-Through Processing. See sections 1.10.1.2.6 ERA with Payment by Card and 1.10.1.4 Card Payments in the 835 for additional information on card payments.
D
Debit
Use when indicating 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. For card processing, use this code for Virtual and other types of cards, excluding Straight-Through Processing. See sections 1.10.1.2.6 ERA with Payment by Card and 1.10.1.4 Card Payments in the 835 for additional information on card payments.
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 when payment is being moved electronically through the ACH Network.
BOP
Financial Institution Option
Use when indicating that the third party processor will choose the method of payment based upon end point requests or capabilities. The Third Party Processor must change the code to reflect the actual payment method used before sending to the payee or another intermediary.
CCC
Credit Card
Use when payment is made by credit card that allows payments to be offset against an account associated with a revolving line of credit.

For information on card payment processing, see sections 1.10.1.2.6, 1.10.1.4, and 1.10.2.3.
CHK
Check
Use when a check is issued for the payment.
DEB
Debit Card
Use when payment is made by a debit card linked to a checking or savings account. A debit card withdraws money from a bank account.

For information on card payment processing, see sections 1.10.1.2.6, 1.10.1.4, and 1.10.2.3.
FWT
Federal Reserve Funds/Wire Transfer - Nonrepetitive
Use when funds are sent via the wire system.
NON
Non-Payment Data
Use when the Transaction Handling Code (BPR01) is H or K, indicating that this is information only and no funds 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
Corporate Credit or Debit plus Addenda (CCD+) (ACH)
Use when BPR04 is ACH and the payment format is CCD+ to move funds and up to 80 characters of data, enough to re-associate 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. See section 1.10.2.3 for more information on re-association.
CTX
Corporate Trade Exchange (CTX) (ACH)
Use when BPR04 is ACH and the payment format is CTX to move dollars and data through the ACH Network. 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
X 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)
Use when reporting the ABA transit routing number, which 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
X 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
X 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
X 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 Receiving Depository Financial Institution and the receiver's account.
CODE
DEFINITION
01
ABA Transit Routing Number Including Check Digits (9 digits)
Use when reporting the ABA transit routing number, which 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
X 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
X 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: Payment Effective Date
If BPR04 is ACH, CCC, or DEB, and BPR03 equals C, this is the date that the money is available to the Payee.
If BPR04 is ACH, CCC, or DEB, and BPR03 equals D, this is the earliest date that the Provider can initiate the debit transaction.
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, this is the creation date for this transaction.
If BPR04 is BOP, the financial institution must define the date by mutual agreement with the creator of this transaction.
Not Used
17
1048
Business Function Code
O 1
ID
1/3
Not Used
18
506
(DFI) ID Number Qualifier
X 1
ID
2
Not Used
19
507
(DFI) Identification Number
X 1
AN
3/12
Not Used
20
569
Account Number Qualifier
O 1
ID
1/3
Not Used
21
508
Account Number
X 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/80
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: Unique Remittance Advice Identification 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 (BPR04 = CHK), this must be the check number.
    If payment is made by EFT (BPR04 = ACH), this is the Payer assigned reference number for this payment, to be passed through the EFT clearing system to the payment receiver. This is NOT the "ACH Trace number" assigned by the originating depository financial institution.
    If this is a non-payment 835 (BPR04 = NON), this must be a unique remittance advice identification number.
    If payment is made through a Third-Party Processor who determines the method of delivery (BPR04 = BOP), the Financial Institution must define this number by mutual agreement with the creator (Payer) of the 835.
    If payment is made by card (BPR04 = CCC or DEB), this must be the card number or card payment identifier. This is NOT the Primary Account Number / PAN. See section 1.10.1.4.1 PCI Compliance for card payment information in the 835 for additional information. Since TRN02 must be unique within the trading partner relationship, reuse of the same card payment identifier in multiple payments with the same Payee is prohibited.
  2. See 1.10.2.3, Reassociation of Dollars and Data, for additional information.
  3. In order to ensure the TRN segment meets the size limitations to be included in the CCD+ Addenda record of the EFT transaction, this element is restricted to a maximum size of 30.
  4. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
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/80
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
  1. If BPR11 is not used, then the maximum length for TRN04 is 20 characters. This will ensure the TRN segment meets the size limitations to fit within the CCD+ addenda record of the ACH transaction.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.

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 amounts represented in this transaction are currencies other than the United States dollar. 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 specifying the Standard ISO code 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
X 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
X 1
ID
3
Not Used
11
373
Date
X 1
DT
8
Not Used
12
337
Time
X 1
TM
4/8
Not Used
13
374
Date/Time Qualifier
X 1
ID
3
Not Used
14
373
Date
X 1
DT
8
Not Used
15
337
Time
X 1
TM
4/8
Not Used
16
374
Date/Time Qualifier
X 1
ID
3
Not Used
17
373
Date
X 1
DT
8
Not Used
18
337
Time
X 1
TM
4/8
Not Used
19
374
Date/Time Qualifier
X 1
ID
3
Not Used
20
373
Date
X 1
DT
8
Not Used
21
337
Time
X 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 identifying the Reference Identification
CODE
DEFINITION
EV
Receiver Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Receiver Identifier
  1. Receiver Identification
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*AFC - CARD SECURITY VERIFICATION CODE

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 payment is made by card that contains a security or Card Security Verification Code (CVC) and the 835 is used as the payment notification. 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✱AFC✱123~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
AFC
Verification Source Code
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Card Security Verification Code
Not Used
3
352
Description
X 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:
For example, 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✱20220317~
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
X 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
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 1
AN
1/35

DTM*036 - CARD 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.
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when payment is made by a card that has an expiration date and the 835 is used as the payment notification. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Example:
DTM✱036✱20221231~
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
Use when the date in DTM02 reflects the expiration date of the payment card.
Required
2
373
Date
X 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Card Expiration Date
When the expiration date on the payment card is not in the CCYYMMDD format, but only includes the month and year (MMYY), default the days (DD) to the last day of the month specified, and default the century to the current century (CC).
Not Used
3
337
Time
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 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.
  3. C0703
    If N107 is present, then N103 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 the 1000A REF Additional Payer Identification, if necessary.
TR3 Example:
N1✱PR✱INSURANCE COMPANY OF TIMBUKTU✱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
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payer Name
This element reflects the name of the Health Plan. In situations where an organization is self-insured, this field could contain the name of the organization's third-party administrator that is recognized by the provider and to which the provider submits its claims. The name reflected here (1000A N102) is the same name on the payment mechanism (i.e., EFT, check, etc.) for accurate reassociation.
Situational
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
SITUATIONAL RULE: Required when N104 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
XV
Standard Unique Health Plan Identifier (HPID)
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Health Plan Identifier (HPID)
Situational
4
67
Identification Code
X 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.
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
Not Used
7
C076
Composite Identification Codes
O 1

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✱201 PARK AVENUE✱SUITE 300~
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 is needed. 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. E0308
    Only one of N403 or N408 may be present.
  3. C0605
    If N406 is present, then N405 is required.
  4. 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
X 1
ID
2
Code specifying the Standard State/Province as defined by appropriate government agency
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
X 1
ID
3/15
Code specifying international postal zone code excluding punctuation and blanks (zip code for United States)
COMMENT: N403 contains the postal code in an unstructured format. N408 contains the postal code in a structured format. When a postal code data field is used, the parties shall agree as to which data element (N403 or N408) shall be used in the transaction set.
SEGMENT SYNTAX: E0308
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
X 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.
INDUSTRY NAME: Payer Country
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
X 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Situational
7
1715
Country Subdivision Code
X 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.
INDUSTRY NAME: Payer Country Subdivision
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

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:
3
Situational Rule:
Required when additional payer identification numbers beyond those in the TRN and Payer N1 segments are needed to uniquely identify the payer to the provider. If not required by this implementation guide, do not send.
TR3 Notes:
The ID available in the TRN or 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 identifying the Reference Identification
CODE
DEFINITION
2U
Payer Identification Number
Use when reporting the proprietary or legacy ID specific to the payer.
HI
Health Industry Number (HIN)
CODE SOURCE: 121: Health Industry Number
NF
National Association of Insurance Commissioners (NAIC) Code
CODE SOURCE: 245: National Association of Insurance Commissioners (NAIC) Code
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*EO - TRANSACTION CREATOR IDENTIFIER

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 the original transaction creator is not the payer.
OR
Required when the original transaction creator has an identifier other than those already provided.
If not required by this implementation guide, do not send.
TR3 Notes:
  1. This segment is not used by third parties between the payer and the payee.
  2. An example of this segment's use includes, but is not limited to: identifying a clearinghouse that created the 835 when the health plan sent a proprietary format to the clearinghouse.
TR3 Example:
REF✱EO✱123345~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
EO
Submitter Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Transaction Creator Identifier
Not Used
3
352
Description
X 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:
2
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 must always include 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. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
TR3 Example:
PER✱CX✱JOHN WAYNE✱TE✱8005551212✱EX✱4255~
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).
Required
3
365
Communication Number Qualifier
X 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
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Payer Contact Communication Number
Situational
5
365
Communication Number Qualifier
X 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
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
X 1
AN
1/2048
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
X 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
X 1
AN
1/2048
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:
2
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 must always include 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. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
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 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). If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Technical Contact Name
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
EM
Electronic Mail
TE
Telephone
UR
Uniform Resource Locator (URL)
Use when there is no central telephone number for the payer entity.
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Payer Contact Communication Number
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when an additional communication contact number is needed or an extension applies to the previous communications contact number. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Situational
6
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when an additional communication contact number is needed or an extension applies to the previous communications contact number. If not required by this implementation guide, do not send.
INDUSTRY NAME: Payer Technical Contact Communication Number
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an additional communication contact number is needed or an extension applies to the previous communications contact number. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
UR
Uniform Resource Locator (URL)
Situational
8
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an additional communication contact number is needed or an extension applies to the previous communications contact number. 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 WEBSITE 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 any 2110 loop Healthcare Policy REF Segment is used or 2100 loop Payment Determination Methodology REF Segment is used
AND
more details are available via the payer Website.
If not required by this implementation guide, do not send.
TR3 Notes:
  1. This is a direct link to the policy location on payer's website (secured or unsecured) when any 2110 loop Healthcare Policy REF Segment is used.
  2. This is a direct link to the fee schedule location on payer's website (secured or unsecured) when any 2100 loop Payment Determination Methodology REF Segment with qualifier AFT is used.
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
X 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
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
This is the payer's website URL where providers can find policy and other related information.
Not Used
5
365
Communication Number Qualifier
X 1
ID
2
Not Used
6
364
Communication Number
X 1
AN
1/2048
Not Used
7
365
Communication Number Qualifier
X 1
ID
2
Not Used
8
364
Communication Number
X 1
AN
1/2048
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.
  3. C0703
    If N107 is present, then N103 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 (when applicable) 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
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payee Name
Situational
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
SITUATIONAL RULE: Required when N104 is used. If not required by this implementation guide, do not send.
See section 1.10.2.22 for additional information.
CODE
DEFINITION
XV
Standard Unique Health Plan Identifier (HPID)
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Health Plan Identifier (HPID)
XX
Standard Unique Health Identifier for Health Care Providers (NPI)
CODE SOURCE: 537: National Provider Identifier (NPI)
Situational
4
67
Identification Code
X 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 the payee has a National Provider Identifier (NPI) and a Billing / Pay-to National Provider Identifier (NPI) was submitted on the claim.ORRequired when reporting the Health Plan Identifier (HPID) or Other Entity Identifier (OEID).If not required by this implementation guide, do not send.See section 1.10.2.22 for additional information.
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
Not Used
7
C076
Composite Identification Codes
O 1

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 BPR01 is equal to U or X and RDM01 is equal to BM where the sender needs to communicate the payee address to the transaction receiver. 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 is needed. 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. E0308
    Only one of N403 or N408 may be present.
  3. C0605
    If N406 is present, then N405 is required.
  4. C0704
    If N407 is present, then N404 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when BPR01 is equal to U or X and RDM01 is equal to BM where the sender needs to communicate the payee address to the transaction receiver. 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
X 1
ID
2
Code specifying the Standard State/Province as defined by appropriate government agency
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
X 1
ID
3/15
Code specifying international postal zone code excluding punctuation and blanks (zip code for United States)
COMMENT: N403 contains the postal code in an unstructured format. N408 contains the postal code in a structured format. When a postal code data field is used, the parties shall agree as to which data element (N403 or N408) shall be used in the transaction set.
SEGMENT SYNTAX: E0308
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
X 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.
INDUSTRY NAME: Payee Country Code
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
X 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Situational
7
1715
Country Subdivision Code
X 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.
INDUSTRY NAME: Payee Country Subdivision Code
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

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:
3
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 identifying 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 Provider Identification Number
PQ
Payee Identification
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*TJ - PAYEE TAX 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:
Required
Segment Repeat:
1
TR3 Example:
REF✱TJ✱123456789~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
TJ
Federal Taxpayer's Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payee Tax Identification Number
Not Used
3
352
Description
X 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 (Split Payment and Remittance) or X (Handling Party's Option to Split Payment and Remittance), and the remittance is to be sent separately from the payment. If not required by this implementation guide, do not send.
TR3 Notes:
Payer and Payee must coordinate this process with the third party processor.
TR3 Example:
RDM✱BM✱Third Party Processor Name~RDM✱OL✱✱www.anyhealthplan.com~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
756
Report Transmission Code
M 1
ID
1/2
Code specifing timing, transmission method or format by which reports are to be sent
CODE
DEFINITION
BM
By Mail
Use when the remittance information will be mailed to the payee at the address identified in this 1000B loop.
EM
E-Mail
Use when the remittance delivery method is encrypted e-mail.
FT
File Transfer
Use when the remittance delivery method is FTP communications.
OL
On-Line
Use when the remittance delivery method is 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 (By Mail). If not required by this implementation guide, do not send.
INDUSTRY NAME: Remittance Recipient Name
When BM (By Mail) is used in RDM01, 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/2048
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 (E-Mail), FT (File Transfer), or OL (On-Line). If not required by this implementation guide, do not send.
Contains URL web address, e-mail address, or FTP 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:
LX✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
554
Assigned Number
M 1
N
1/9
Number assigned for differentiation within a transaction set
INDUSTRY NAME: Claim Grouping Identifier

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 when there is a need to identify provider subsidiaries whose remittance information is contained in the 835 transaction transmitted to a single provider entity [e.g., 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 uses data elements TS313, TS315, TS317, TS318 and TS320 through TS324. Each monetary amount element pertains to the provider identified in TS301.
TR3 Example:
TS3✱1234567890✱11✱20171031✱10✱130957.66~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
127
Reference Identification
M 1
AN
1/80
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
  1. This is the provider number. When the provider has an NPI, this must be the provider's NPI.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Required
2
1331
Facility Code Value
M 1
AN
1/3
Code identifying where services were, or may be, performed; the National Uniform Billing Committee (NUBC) Facility 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
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
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
Total number of claims is defined as the total count of Claim Payment Information (CLP) segments in the current iteration of the 2000 Loop.
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. The total of reported charges (Total Claim Charge Amount) is defined as the sum of the Total Claim Charge Amount (CLP03) in the Claim Payment Information (CLP) segments in the current iteration of the 2000 Loop.
  2. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 Healthcare Common Procedure 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
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: TS318 is the total Healthcare Common Procedure 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
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 RAS segment with a Claim Adjustment Reason Code value of 89.
  2. See TR3 note 3.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total MSP Patient Liability Met Amount
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Patient Reimbursement Amount
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 3.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.

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.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 non-covered day count is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Total Noncovered Day Count
  1. See TR3 note 2.
  2. See sections 1.10.2.4.2 and 1.10.2.4.6 for additional information.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
  1. See TR3 note 2.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.

CLP - CLAIM PAYMENT INFORMATION

X12 Name:
Claim Level Data
X12 Purpose:
To supply information common to all services of a claim
X12 Syntax:
P1112
If either CLP11 or CLP12 is present, then the other is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
CLP✱7722337✱1✱211366.97✱138018.4✱✱✱119932404007801✱11✱1✱✱DCM:123✱✱✱✱✱72~
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: Provider's Assigned Claim Identifier
Use this number for the Provider's Assigned Claim Identifier. If the Provider's Assigned Claim Identifier is not present on the incoming claim, enter a single zero. The value in CLP01 must be identical to any value received as the Provider's Assigned Claim Identifier on the original claim (characters 1-35 of the CLM01 of the 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, refer to the NCPDP Pharmacy Reference Guide to the X12/007030X322 Health Care Claim Payment/Advice (835), available from NCPDP at http://www.ncpdp.org.

This identifier is generated by the provider for the purposes of reassociation to their claim accounts receivable, and must not be modified. This identifier, as submitted in the 837, is returned in 835 and/or other transactions. This identifier is not to be validated beyond standard TR3 syntax and semantic rules.
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 RAS segment in conjunction with this claim status code.
CODE
DEFINITION
1
Processed as Primary
Use when the claim was adjudicated by the current payer as primary regardless of whether any part of the claim was paid. If the claim was rejected because the payer believes they are not primary, use the appropriate code for secondary or tertiary processing.
2
Processed as Secondary
Use when the claim was adjudicated by the current payer as secondary regardless of whether any part of the claim was paid OR the claim was denied because the payer determined that they should be secondary. Refer to the LoopID 2105 Corrected Priority Payer Name N1 segment requirements for additional information.
3
Processed as Tertiary
Use when the claim was adjudicated by the current payer as tertiary regardless of whether any part of the claim was paid OR the claim was denied because the payer determined that they should be tertiary. Refer to the LoopID 2105 Corrected Priority Payer Name N1 segment requirements for additional information.
19
Processed as Primary, Forwarded to Additional Payer(s)
Use when the claim was adjudicated by the current payer as primary regardless of whether any part of the claim was paid and the claim was forwarded to another payer(s). If the claim was rejected because the payer believes they are not primary, use the appropriate code for secondary or tertiary processing. When this code is used, the Crossover Carrier Name NM1 segment is required.
20
Processed as Secondary, Forwarded to Additional Payer(s)
Use when the claim was forwarded to another payer(s) and the claim was adjudicated by the current payer as secondary regardless of whether any part of the claim was paid, or when a primary claim was denied because the payer determined that they should be secondary. When this code is used, the Crossover Carrier Name NM1 segment is required.
21
Processed as Tertiary, Forwarded to Additional Payer(s)
Use when the claim was forwarded to another payer(s) and the claim was adjudicated by the current payer as tertiary (or subsequent) regardless of whether any part of the claim was paid or when a primary or secondary claim was denied because the payer determined that they should be tertiary (or subsequent). When this code is used, the Crossover Carrier Name NM1 segment is required.
23
Not Our Claim, Forwarded to Additional Payer(s)
Use when 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
Use when responding to a predetermination request. See section 1.10.2.7 for additional information.
32
Reversal of Previous Payment for Primary Claim
Use when identifying a reversal of a previous payment for a Primary claim. See Section 1.10.2.8 for usage information
33
Reversal of Previous Payment for Secondary Claim
Use when identifying a reversal of a previous payment for a Secondary claim. See Section 1.10.2.8 for usage information.
34
Reversal of Previous Payment of Tertiary Claim
Use when identifying a reversal of a previous payment for a Tertiary (or subsequent) claim. See Section 1.10.2.8 for usage information.
35
Patient/Subscriber Not Recognized
Use when the Patient/Subscriber is not recognized, and the claim was not forwarded to another payer.
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. 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.
  2. See 1.10.2.1.2, Claim Balancing, in this implementation guide for additional information.
  3. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  4. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
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.2, Claim Balancing, in this implementation guide for additional information.
  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.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
5
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: CLP05 is the patient responsibility amount.
SITUATIONAL RULE: Required when any 2100 or 2110 Loop RAS segment has a Claim Adjustment Group code (RAS02) indicating Patient Responsibility and the sum of the associated monetary Adjustment Amount (RAS01) values is not equal to 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 RAS segments at the 2100 or 2110 loop level with a Claim Adjustment Group Code (RAS02) indicating Patient Responsibility. Amounts associated with Claim Adjustment Group Codes other than Patient Responsibility (e.g. Payer Initiated) should not be included.
  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. See section 1.10.2.8, Reversals and Corrections, for additional information.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
6
1032
Claim Filing Indicator Code
O 1
ID
1/2
Required
7
127
Reference Identification
O 1
AN
1/80
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
  1. Use this number for the payer's internal control number. This number must apply to the entire claim.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Situational
8
1331
Facility Code Value
O 1
AN
1/3
Code identifying where services were, or may be, performed; the National Uniform Billing Committee (NUBC) Facility 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. This number was received in CLM05-01 of the 837 claim.
  2. 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.
Situational
9
1325
Claim Frequency Type Code
O 1
ID
1
Code specifying the Type of Bill Frequency Code. It is the last digit of Type of Bill in the UB manual, as defined by the National Uniform Billing Committee
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-03 of the 837 Claim.
CODE SOURCE 235: Claim Frequency Type Code
Not Used
10
1352
Patient Discharge Status
O 1
ID
1/2
Situational
11
C022
Health Care Code Information
X 1
To send health care codes and their associated dates, amounts and quantities
SEMANTIC: CLP11 is used to convey diagnostic related group code.
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
  7. C022-10 is the attribute of the code in C022-02 from the same code list.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when a DRG or grouping methodology was used to adjudicate the claim. If not required by this implementation guide, do not send.
Required
11-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
Use this field to report the DRG type qualifier used to adjudicate the claim.
CODE
DEFINITION
ABS
Assigned by Sender
AU
All Patient Refined Diagnosis Related Groups (APR-DRG)
CODE SOURCE: 477: All Patient Refined Diagnosis Related Groups (APR-DRG)
AW
All Patient Diagnosis Related Groups (AP-DRG)
CODE SOURCE: 476: All Patient Diagnosis Related Groups (AP-DRG)
AX
Ambulatory Patient Groups (APG)
CODE SOURCE: 475: Ambulatory Patient Groups (APG)
DAP
All Patient, Severity-Adjusted DRGs (APS-DRG)
DCM
Medicare DRG (CMS-DRG & MS-DRG)
DIR
International-Refined DRGs (IR-DRG)
DR
Diagnosis Related Group (DRG)
DRD
Refined DRGs (R-DRG)
DSD
Severity DRGs (S-DRG)
EP
Enhanced Ambulatory Patient Groups (EAPG)
CODE SOURCE: 980: Enhanced Ambulatory Patient Groups
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
Use this field to report the DRG code or grouping methodology used to adjudicate the claim.
Not Used
11-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
11-4
1251
Date Time Period
X 1
AN
1/35
Not Used
11-5
782
Monetary Amount
O 1
R
1/18
Not Used
11-6
380
Quantity
O 1
R
1/15
Not Used
11-7
799
Version Identifier
O 1
AN
1/30
Not Used
11-8
1271
Industry Code
X 1
AN
1/30
Not Used
11-9
1271
Industry Code
X 1
AN
1/30
Not Used
11-10
1271
Industry Code
O 1
AN
1/30
Situational
12
380
Quantity
X 1
R
1/15
Numeric value of quantity
SEMANTIC: CLP12 is the diagnosis-related group (DRG) weight.
SEGMENT SYNTAX: P1112
SITUATIONAL RULE: Required for institutional claims when the claim was adjudicated using a DRG (CLP11-01 is present and not equal to AX or EP). If not required by this implementation guide, do not send.
INDUSTRY NAME: Diagnosis Related Group (DRG) Weight
This is the adjudicated DRG weight for the DRG reported in CLP11. When the payer does not consider DRG Weight during adjudication, populate this element with "1".
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 for the DRG reported in CLP11.
Not Used
14
1073
Yes/No Condition or Response Code
O 1
ID
1
Situational
15
280
Exchange Rate
O 1
R
4/10
Value to be used as a multiplier conversion factor to convert monetary value from one currency to another
SITUATIONAL RULE: Required when the currency of the originally submitted claim is different than the currency of adjudication/payment. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Exchange Rate
This is the exchange rate used by the payer when converting from the original submitted currency to the adjudication/payment currency. For instance if a submitted charge of 100 British Pounds was converted to $125 then the exchange rate reported would be 1.250.
Required
16
1732
Source of Payment Typology Code
O 1
ID
2/6
Code identifying payer types in the most granular way
SEMANTIC: CLP16 is the Source of Payment Typology Code (see Code Source 944).
The Source of Payment Typology provides a standard for reporting the payer and the payer's product. The source of payment type is determined by the organization that provides the payment and must be reported using the most granular level of detail defining the payer and the payer's product.
CODE SOURCE 944: Source of Payment Typology

RAS - CLAIM ADJUSTMENT INFORMATION

X12 Name:
Reason Adjustment
X12 Purpose:
To supply Claim Adjustment Reason Codes and amounts as needed for an entire claim or for a particular service within the claim being paid
X12 Comments:
Adjustment information is intended to help the provider balance the remittance information. Adjustment amounts must 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 are being adjusted at the claim level. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Payers must use this RAS segment to report claim level adjustments that cause the amount paid to differ from the amount originally charged. See sections 1.10.2.1, Financial Balancing, and 1.10.2.4, Claim Adjustment Information and Service Adjustment Information Segment Theory, for additional information.
  2. See the SVC TR3 Note #2 for details about per diem adjustments.
TR3 Example:
RAS✱125.32✱PR✱1~RAS✱25✱PR✱3~RAS✱200✱CO✱6^7~RAS✱500✱CO✱45:HE:N13✱1~RAS✱1225✱CO✱16:HE:M24^15:HE:N517✱2~RAS✱2225✱CO✱16:HE:M44:M45:M49^146:HE:MA63:MA65~RAS✱2100✱OA✱18:HE:N522:N702~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: RAS01 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. This amount must not be zero (0).
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Required
2
1785
Claim Adjustment Group Code
M 1
AN
1/10
Code identifying the general category of payment adjustment.
Evaluate the usage of group codes in RAS02 based on the following order for their applicability to an adjustment: Patient Responsibility, Contractual Obligation, Payer Initiated, Other Adjustments. (Note: This does not mean that the adjustments must be reported in this order.)

See Front Matter Section 1.10.2.4.5, Claim Adjustment Group Code Usage, for additional information.
CODE SOURCE 974: Claim Adjustment Group Codes
Required
3
C058
Adjustment Reason
M 15
To provide a reason and related explanation for a Health Care Claim or Service change in payment versus the original submitted charges
SEMANTIC: Position of data in the repeating composite data element conveys no significance.
X12 COMPOSITE SYNTAX NOTES:
  1. P0203
    If either C05802 or C05803 is present, then the other is required.
  2. C0403
    If C05804 is present, then C05803 is required.
  3. C0504
    If C05805 is present, then C05804 is required.
  4. C0605
    If C05806 is present, then C05805 is required.
  5. C0706
    If C05807 is present, then C05806 is required.
X12 COMPOSITE SEMANTIC NOTES: C05802 qualifies C05803, C05804, C05805, C05806 and C05807.
  1. More than one iteration of this composite may be provided only when the entire claim submitted charge (CLP03) is being adjusted by this RAS segment (RAS01 equals CLP03) and there are multiple adjustment reasons that are each applicable to the full amount in RAS01.

    See 1.10.2.4.2 Claim/Service Adjustment Information Segment for additional information.
  2. This composite identifies the reason for the adjustment of the dollar amount identified in RAS01.
Required
3-1
1034
Claim Adjustment Reason Code
M 1
ID
1/5
Code identifying the detailed reason the adjustment was made
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139: Claim Adjustment Reason Code
Situational
3-2
1270
Code List Qualifier Code
X 1
ID
1/3
Code identifying a specific industry code list
COMPOSITE SYNTAX: P0203
SITUATIONAL RULE: Required when a remark code is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
CODE
DEFINITION
HE
Remittance Advice Remark Code
CODE SOURCE: 411: Remittance Advice Remark Code
RM
Insurance Industry Specific Remark Codes
CODE SOURCE: 973: Insurance Industry Specific Remark Codes
Situational
3-3
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: P0203, C0403
SITUATIONAL RULE: Required when a remark code is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-4
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0403, C0504
SITUATIONAL RULE: Required when an additional remark code not already provided in this composite is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-5
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0504, C0605
SITUATIONAL RULE: Required when an additional remark code not already provided in this composite is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-6
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0605, C0706
SITUATIONAL RULE: Required when an additional remark code not already provided in this composite is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-7
1271
Industry Code
O 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0706
SITUATIONAL RULE: Required when an additional remark code not already provided in this composite is necessary for the provider to fully understand the adjustment message for the claim adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
4
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: RAS04 is the units of service being adjusted.
SITUATIONAL RULE: Required when the RAS03 adjustment reason code is related to non-covered days. If not required by this implementation guide, do not send.
INDUSTRY NAME: Adjustment Quantity
A positive value decreases the quantity, and a negative value increases the quantity.

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. Any necessary identification number should be provided 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/Subscriber Name NM1 segment identifies the adjudicated Subscriber Name and ID information if different than what was submitted on the claim.
TR3 Example:
NM1✱QC✱1✱Shepard✱Sam✱A✱✱✱MI✱452114586~
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 identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
Situational
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when the claim is not a retail pharmacy claimORRequired when the claim is a retail pharmacy claim and the information was provided on the original claim.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 was provided on the original claim. 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's middle name or initial was provided on the original claim. 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 the patient's suffix was provided on the original claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Name Suffix
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
II
Standard Unique Health Identifier for each Individual in the United States
Use when reporting the HIPAA Individual Patient Identifier.
MI
Member Identification Number
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the Patient identifier was provided on the original claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Identifier
Not Used
10
706
Entity Relationship Code
X 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/80

NM1*IL - 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 the 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 submitted 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)
  3. The Corrected Patient/Subscriber Name NM1 segment identifies the adjudicated Subscriber Name and ID information if different than what was submitted on the claim.
TR3 Example:
NM1✱IL✱1✱Shephard✱Jessica✱✱✱✱MI✱452114458~
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 identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when submitted on the claim. 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 was provided on the original claim. 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 was provided on the claim. 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) AND the suffix was provided on the original claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber Name Suffix
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
Use when NM102 = 2 and the Federal Taxpayer's Identifier is the primary identifier.
II
Standard Unique Health Identifier for each Individual in the United States
Use when reporting the HIPAA Individual Patient Identifier.
MI
Member Identification Number
Use when indicating the subscriber's identification number as assigned by the payer. (For example, Insureds ID, Subscribers ID, Health Insurance Claim Number (HIC), etc.).
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the Identification Code was provided on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Subscriber Identifier
Not Used
10
706
Entity Relationship Code
X 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/80

NM1 - CORRECTED PATIENT/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:
2
Situational Rule:
Required when the information submitted on the claim is different from the information on file with the payer. If not required by this implementation guide, do not send.
TR3 Notes:
Use this NM1 segment to provide information as it exists in the payer system. All portions of the name must be sent (NM103, NM104, and NM105) when information exists in the payer's system.
TR3 Example:
NM1✱COS✱1✱Shepard✱Sam✱A✱✱✱IN✱452114586~
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
COP
Corrected Patient
COS
Corrected Subscriber
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when the adjudicated patient/subscriber last or organization name is different than the last or organization name submitted on the claim, or when NM104 and NM105 are being sent and the information exists in the payer's system. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Subscriber Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the patient/subscriber is a person and has a first name and the adjudicated first name is different than the first name submitted on the claim, or when NM103 and NM105 are being sent and the information exists in the payer's system. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Subscriber First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the patient/subscriber is a person and has a middle name and the adjudicated middle name is different than the middle name submitted on the claim, or when NM103 and NM104 are being sent and the information exists in the payer's system. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or 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 patient/subscriber is a person and has a name suffix and the adjudicated name suffix is different than the name suffix submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Subscriber Name Suffix
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
IN
Changed Unique Identification Number
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the adjudicated patient/subscriber identification number is different than the identification submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Corrected Patient or Subscriber Identification Number
Not Used
10
706
Entity Relationship Code
X 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/80

NM1*SJ - 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 service provider is different from the payee. If not required by this implementation guide, do not send.
TR3 Notes:
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✱SJ✱2✱Service Physicians Inc✱✱✱✱✱XX✱6201254569~
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
SJ
Service Provider
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
SITUATIONAL RULE: Required when the information was provided on the original claim. If not required, may be provided at sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Service Provider Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the Service Provider is a person (NM102=1), NM103 is used AND the information is known by the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Service Provider First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the Service Provider is a person (NM102=1), NM103 is used AND the information is known by the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Service Provider 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 Service Provider is a person (NM102=1), NM103 is used, and the name suffix is necessary to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Service Provider Name Suffix
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
XX
Standard Unique Health Identifier for Health Care Providers (NPI)
CODE SOURCE: 537: National Provider Identifier (NPI)
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required for providers in the United States or its territories when the provider is eligible to receive a National Provider Identifier (NPI).ORRequired for providers not in the United States or its territories when the provider has received an NPI. If not required by this implementation guide, do not send.
INDUSTRY NAME: Service Provider Identifier
Not Used
10
706
Entity Relationship Code
X 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/80

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:
10
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:
  1. 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.
  2. When the claim is transferred to more than 1 carrier, use this segment to report all crossover names and reference numbers.
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 identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Crossover 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
X 1
ID
1/2
Code specifying 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
Standard Unique Health Plan Identifier (HPID)
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Health Plan Identifier (HPID)
Required
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Crossover Carrier Identifier
Not Used
10
706
Entity Relationship Code
X 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/80

MIA - INPATIENT ADJUDICATION INFORMATION

X12 Name:
Inpatient Adjudication
X12 Purpose:
To provide claim level data related to the adjudication of inpatient claims
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for all inpatient claims when 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. 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:
MIA✱✱✱✱0138018.4~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Not Used
1
380
Quantity
O 1
R
1/15
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. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS Operating Outlier Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 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 value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
5
127
Reference Identification
O 1
AN
1/80
Situational
6
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA06 is the disproportionate share amount.
SITUATIONAL RULE: Required when the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Disproportionate Share Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim MSP Pass-through Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim PPS Capital Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital FSP DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital HSP DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital DSH DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
12
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA12 is the old capital amount.
SITUATIONAL RULE: Required when the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Old Capital Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital IME amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Operating Hospital Specific DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
15
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: MIA15 is the cost report days.
SITUATIONAL RULE: Required when 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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Operating Federal Specific DRG Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim PPS Capital Outlier Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
18
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA18 is the indirect teaching amount.
SITUATIONAL RULE: Required when the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Indirect Teaching Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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 the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Nonpayable Professional Component Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
20
127
Reference Identification
O 1
AN
1/80
Not Used
21
127
Reference Identification
O 1
AN
1/80
Not Used
22
127
Reference Identification
O 1
AN
1/80
Not Used
23
127
Reference Identification
O 1
AN
1/80
Situational
24
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: MIA24 is the capital exception amount.
SITUATIONAL RULE: Required when the value is different than zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: PPS-Capital Exception Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.

MOA - OUTPATIENT ADJUDICATION INFORMATION

X12 Name:
Outpatient Adjudication
X12 Purpose:
To provide claim level data related to the adjudication of outpatient claims
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for outpatient/professional claims 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✱50✱100~
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. 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 Healthcare Common Procedure Coding System (HCPCS) payable amount.
SITUATIONAL RULE: Required when the outpatient institutional claim HCPCS Payable Amount is not zero. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim HCPCS Payable Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
3
127
Reference Identification
O 1
AN
1/80
Not Used
4
127
Reference Identification
O 1
AN
1/80
Not Used
5
127
Reference Identification
O 1
AN
1/80
Not Used
6
127
Reference Identification
O 1
AN
1/80
Not Used
7
127
Reference Identification
O 1
AN
1/80
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. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim ESRD Payment Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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. If not required by this implementation guide, do not send.
INDUSTRY NAME: Nonpayable Professional Component Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.

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:
10
Situational Rule:
Required when reference identifiers specified in REF01 are applicable to the claim, used in the adjudication process, or a result of the adjudication process. If not required by this implementation guide, do not send.
TR3 Example:
REF✱EA✱44444TH56~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
1L
Group or Policy Number
28
Employee Identification Number
5N
Citation of Statute
Use when reporting the jurisdiction rule/statute reference identification number. If used, the PER Workers Compensation Website segment is required to provide an un-secure WEB contact point where the provider can access the full text description of the jurisdiction rule /statute reference.
9A
Repriced Claim Reference Number
9C
Adjusted Repriced Claim Reference Number
EA
Medical Record Identification Number
IG
Insurance Policy Number
M7
Medical Assistance Category
Use when advising the provider of the Prepaid Medical Assistance Program (PMAP) code which was used for claim adjudication.
OX
Statement Number
Use when reporting Jurisdiction/payer remittance statement number.
Y4
Agency Claim Number
Use when reporting the Property & Casualty Claim Number.
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*F8 - ORIGINAL PAYER CLAIM 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:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the payment is for a corrected claim and Payer Claim Control Number (CLP07) is different than the previous Payer Claim Control Number (CLP07) of the original claim payment / reversal related to this correction. If not required by this implementation guide, do not send.
TR3 Notes:
See section 1.10.2.8, Reversals and Corrections, for additional information.
TR3 Example:
REF✱F8✱24693640801286913~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
F8
Original Reference Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Original Payer Claim Control Number
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*CE - CLASS OF CONTRACT CODE

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 the adjudication of the claim or services was impacted by the terms of a contract with the healthcare provider or by regulation. If not required by this implementation guide, do not send.
TR3 Notes:
Payers must develop the identifiers necessary to relay the plan information to the payee. The identifiers must be global, rather than payee-specific. Payers must provide a method to communicate the identifiers to payees in a timely fashion.
TR3 Example:
REF✱CE✱Network A~REF✱CE✱Network A✱✱2U:123456789~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
See section 1.10.2.15 for information on the use of Class of Contract Code.
CODE
DEFINITION
CE
Class of Contract Code
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Class of Contract Code
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Situational
4
C040
Reference Identifier
O 1
To identify one or more reference numbers or identification numbers as specified by the Reference Qualifier
SEMANTIC: REF04 contains data relating to the value cited in REF02.
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C04003 or C04004 is present, then the other is required.
  2. P0506
    If either C04005 or C04006 is present, then the other is required.
SITUATIONAL RULE: Required when the entity that contracts directly with the health care provider is not the same as the payer identified in Loop 1000A and information is known and allowable to supply. If not required by this implementation guide, do not send.
Required
4-1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
2U
Payer Identification Number
Required
4-2
127
Reference Identification
M 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
INDUSTRY NAME: Contracting Entity Payer Identifier
  1. This is the identifier of the entity that assigned the Class of Contract Code in REF02 (the entity who is the party to the contract with the provider). This is the Health Plan Identifier (HPID) when mandated for use and the entity has a Health Plan Identifier (HPID). Otherwise, it is the Federal Tax ID of the entity. This ID is used by the provider with the Class of Contract Code to uniquely identify the contract or regulatory requirement that establishes the payment basis for this claim.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
4-3
128
Reference Identification Qualifier
X 1
ID
2/3
Not Used
4-4
127
Reference Identification
X 1
AN
1/80
Not Used
4-5
128
Reference Identification Qualifier
X 1
ID
2/3
Not Used
4-6
127
Reference Identification
X 1
AN
1/80

REF - SERVICE PROVIDER SECONDARY 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:
3
Situational Rule:
Required when additional service 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✱LU✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
A6
Provider Identifier
This code designates a proprietary provider number assigned by the payer identified in the payer name loop (1000A) associated with this claim. This is true regardless of whether the payer is Medicare, Medicaid, a Blue Cross Blue Shield plan, a Commercial plan, or any other health plan.
LU
Location Number
TJ
Federal Taxpayer's Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Service Provider Secondary Identification
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - PAYMENT DETERMINATION METHODOLOGY

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 for non-pharmacy claims when the "Payment Determination Methodology" identified by the REF01 qualifier was used to adjudicate and derive the allowed amount for the claim. If not required by this implementation guide, do not send.
TR3 Notes:
Use this segment to convey information related to pricing. CLP11 is used for information related to clinical grouping (e.g. DRG).
TR3 Example:
REF✱9V✱TSUR~REF✱APC✱6541~REF✱AFT✱033214~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
9V
Payment Category
Use when reporting payer specific payment determination methodologies identified in REF02. For example, use when reporting various tiers, rates, per diems, or percentage of charge. These are examples and should not be considered the only payment determination methodologies that can be used with this qualifier.
AFT
Fee Schedule Identifier
Use when advising the provider of the contracting entity's agreed upon enumerated fee schedule identifier for the specific fee schedule/contract that was used to adjudicate and derive the allowed amount for the services. If the contracting entity has the fee schedule on their website, the URL must be supplied in the Payer Website Contact Information PER at 1000A loop.
APC
Ambulatory Payment Classification
CODE SOURCE: 468: Ambulatory Payment Classification
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payment Determination Methodology
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*BLT - ORIGINAL CLAIM 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:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This segment reports the type and method of claim originally submitted by the provider. It provides information needed in this transaction to split the file as needed and post to the accounts receivable system.
TR3 Example:
REF✱BLT✱P✱✱PHC:E~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
BLT
Billing Type
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Original Claim Type
The information in this field must reflect the original claim type received by the payer. Codes reported in REF02 must be one of the following:
Code Description
P Professional
IP Institutional Inpatient
OP Institutional Outpatient
D Dental
RX Pharmacy
Not Used
3
352
Description
X 1
AN
1/80
Required
4
C040
Reference Identifier
O 1
To identify one or more reference numbers or identification numbers as specified by the Reference Qualifier
SEMANTIC: REF04 contains data relating to the value cited in REF02.
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C04003 or C04004 is present, then the other is required.
  2. P0506
    If either C04005 or C04006 is present, then the other is required.
Required
4-1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
PHC
Process Handling Code
Required
4-2
127
Reference Identification
M 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
INDUSTRY NAME: Method of Claim Submission
The information reported in this element must reflect the method in which the claim reported in this CLP was received by the payer. Codes reported in REF04-02 must be one of the following:
Code Description
C Crossover
Use when the claim was automatically crossed over from one payer to another.
D Direct Data Entry
Use when the claim was manually entered through a DDE terminal or web portal.
E Electronic Submission
Use when the claim was electronically submitted through a transmission or via upload by web portal.
O Other
Use when the claim was submitted in a different format other than DDE, web portal, electronic or paper.
P Paper
Use when the claim was submitted via paper, including paper claims put through an OCR process by the payer.
Not Used
4-3
128
Reference Identification Qualifier
X 1
ID
2/3
Not Used
4-4
127
Reference Identification
X 1
AN
1/80
Not Used
4-5
128
Reference Identification Qualifier
X 1
ID
2/3
Not Used
4-6
127
Reference Identification
X 1
AN
1/80

REF - CLAIM AUTHORIZATION 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:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when a specific authorization identifier is applicable to the claim, used in the adjudication process, or is a result of the adjudication process. If not required by this implementation guide, do not send.
TR3 Example:
REF✱BB✱12346789A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
BB
Authorization Number
Use when supplying an authorization number that was assigned during and used by the adjudication process.
G1
Prior Authorization Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Claim Authorization Number
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

DTM - STATEMENT DATES

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 Service Dates are not supplied at the Service Payment Information Loop, Loop ID 2110, and CLP02 does not equal 25 (Predetermination). If not required by the implementation guide, do not send.
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. When payment is being made in advance of services, the use of future dates is allowed.
TR3 Example:
DTM✱233✱20220916~
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
233
Claim Statement Period End
Required
2
373
Date
X 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
If a Claim Statement Period Start (Statement From) date is reported without a Claim Statement Period End (Statement To) date, it is assumed that the Statement From date and Statement To date are the same. If only the Statement To date is reported, the Statement From date is assumed to be different from the Statement To date but not reported at the payer's discretion.
Not Used
3
337
Time
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 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✱20221001~
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
X 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
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 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 when state or federal regulations or the provider contract mandates interest payment or prompt payment discounts based upon the receipt date of the claim by the payer on non-pharmacy claims.
Or
Required when state or federal regulations or the provider contract mandates interest payment or prompt payment discounts based upon the receipt date of the claim by the payer and the prescription/service date of service is not equal to the claim received date for pharmacy claims.

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✱20221124~
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
X 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
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 1
AN
1/35

DTM*242 - CLEAN CLAIM 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 a clean claim date, as determined by the payer, is different than the claim received date and state/federal requirements (including workers' compensation) or provider contracts utilize the clean claim date for payment decisions. If not required by this implementation guide, do not send.
TR3 Notes:
Examples of use of this segment include complete bill determinations, interest payments or prompt payment discounts.
TR3 Example:
DTM✱242✱20220106~
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
242
Actual Start
Required
2
373
Date
X 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Clean Claim Date
Not Used
3
337
Time
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 1
AN
1/35

DTM*439 - CORRECTED ACCIDENT 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 the accident date submitted on a property and casualty claim is different from the date on file with the payer. If not required by this implementation guide, do not send.
TR3 Example:
DTM✱439✱20220106~
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
439
Accident
Required
2
373
Date
X 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Corrected Accident Date
Not Used
3
337
Time
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 1
AN
1/35

DTM*431 - CORRECTED ONSET OF CURRENT SYMPTOMS OR ILLNESS 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 the Onset of Current Symptoms or Illness date submitted on a property and casualty claim is different from the date on file with the payer. If not required by this implementation guide, do not send.
TR3 Example:
DTM✱431✱20220106~
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
431
Onset of Current Symptoms or Illness
Required
2
373
Date
X 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEGMENT SYNTAX: R020305
INDUSTRY NAME: Corrected Onset of Current Symptoms or Illness Date
Not Used
3
337
Time
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 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 must always include 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. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
TR3 Example:
PER✱CX✱JOHN WAYNE✱TE✱8005551212✱EX✱4255~
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 any of the PER02s in the 1000A loop. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Name
Required
3
365
Communication Number Qualifier
X 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
X 1
AN
1/2048
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
X 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
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when PER05 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Communications Number
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communication contact number (PER06). If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Situational
8
364
Communication Number
X 1
AN
1/2048
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

PER - ENTITY SELF-INSURED PLAN / JURISDICTION CONTACT

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 the patient/insured is a member in a self-insured plan that is different than the payer identified in loop 1000A.
OR
Required when a payer has reported a jurisdiction/payer remittance information statement identification number in loop 2100 REF Other Claim Related Identification, REF01 value "OX", on a workers' compensation claim.

If not required by this implementation guide, do not send.
TR3 Notes:
  1. Entity Self-Insured Plan
    This information identifies the contact to discuss ERISA coverage issues, extending coverage request and/or obtaining payment for services not covered by the Benefit Plan; for example, experimental/investigation procedures.

    The Jurisdiction/Payer Remittance Information Statement identifies the unsecure public jurisdiction/payer website URL location where the provider can access the full text description of the jurisdiction/payer remittance information statement.
  2. 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 must always include 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. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
TR3 Example:
PER✱AF✱JOHN DOE✱TE✱3035551212~PER✱IC✱JURISDICTION PAYER✱UR✱www.payer.com/jurisdictionpolicies.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
AF
Authorized Financial Contact
Use when reporting the Entity Self-Insured Plan contact information.
IC
Information Contact
Use when reporting the jurisdiction/payer name.
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when the name of the self-insured plan to contact is not already defined or is different than the payer in loop 1000AORthe jurisdiction is not already defined or is different than the payer in REF - Other Claim Related information in loop 2100.If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Name
If the PER01 value is 'AF' then this is the Entity Self-Insured Plan contact name.

If PER01 value is 'IC' then this is the jurisdiction/payer name.
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
If the PER01 value is 'IC' then the only PER03 qualifier that can be used is 'UR'.
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Required
4
364
Communication Number
X 1
AN
1/2048
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
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when PER01 is 'AF' and 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
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when PER01 is 'AF' and a second communication contact number is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Claim Contact Communications Number
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communication contact number (PER06). If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Situational
8
364
Communication Number
X 1
AN
1/2048
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

PER*CN - WORKERS' COMPENSATION PAYER WEBSITE

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 a workers' compensation payer has reported a jurisdiction rule/statute identification number in loop 2100 Other Claim Payment Identification REF Segment REF01 with a value of '5N'. If not required by this implementation guide, do not send.
TR3 Notes:
This information identifies the public jurisdiction/payer website URL location (secured or unsecured) where the provider can access the full text description of the jurisdiction rule/statute that was used for the denial or adjustment of a claim. Used for workers' compensation only.
TR3 Example:
PER✱CN✱JURISDICTION PAYER✱UR✱www.payer.com/jurisdictionpolicies.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
CN
General Contact
Required
2
93
Name
O 1
AN
1/60
Free-form name
INDUSTRY NAME: Jurisdiction Name
Required
3
365
Communication Number Qualifier
X 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
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Jurisdiction/Payer Website URL
Not Used
5
365
Communication Number Qualifier
X 1
ID
2
Not Used
6
364
Communication Number
X 1
AN
1/2048
Not Used
7
365
Communication Number Qualifier
X 1
ID
2
Not Used
8
364
Communication Number
X 1
AN
1/2048
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

AMT*B6 - CLAIM ALLOWED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Used to report this payer's allowed amount that was used in adjudicating the claim, prior to considering patient responsibility. See section 1.10.2.13 for information on Secondary Payment Reporting. Report the amount, even when zero (0). This must be equal to the sum of the allowed amounts at the service line (Loop 2110, AMT01=B6). 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 specifying the amount qualifier
CODE
DEFINITION
B6
Allowed - Actual
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Claim Allowed Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

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:
12
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.
  3. Supplemental information reported at the Service level (2110 loop) AMT Segment is not repeated at the claim level (2100 loop) AMT Segment.
TR3 Example:
AMT✱T✱45~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code specifying the amount qualifier
CODE
DEFINITION
AU
Coverage Amount
Use when reporting the total covered charges. This is not used for the allowed amount.
D8
Discount Amount
Use when reporting a Prompt Pay Discount Amount. See Section 1.10.2.9 (Interest and Prompt Payment Discounts) for additional information.
DY
Per Day Limit
F5
Patient Amount Paid
Use when reporting the amount the patient has already paid.
I
Interest
See section 1.10.2.9 (Interest and Prompt Payment Discounts) for additional information.
NL
Negative Ledger Balance
Use when the payer is Medicare Part A or Medicare Part B and reporting a Negative Ledger Balance.
T
Tax
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
  1. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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
Use when reporting the number of prescriptions for the patient on an inpatient claim when known by the payer.
VS
Visits
Use when the inpatient visit count is greater than 1.
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
X 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
X 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:
Required
Segment Usage:
Situational
Segment Repeat:
99
Situational Rule:
Required when remark codes are necessary for the provider to fully understand the adjudication message for the claim. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
Remark codes reported in the LQ segment have no direct relationship to any Claim Adjustment Reason Code reported in a RAS segment. These remark codes stand alone and provide a message related to the claim as a whole. See section 1.10.2.4 for additional information.
TR3 Example:
LQ✱HE✱MA15~
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
Remittance Advice Remark Code
CODE SOURCE: 411: Remittance Advice Remark Code
RM
Insurance Industry Specific Remark Codes
CODE SOURCE: 973: Insurance Industry Specific Remark Codes
RX
National Council for Prescription Drug Programs Reject Codes
CODE SOURCE: 530: National Council for Prescription Drug Programs Reject Codes
Required
2
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
SEGMENT SYNTAX: C0102
INDUSTRY NAME: Remark Code

N1*COR - CORRECTED PRIORITY PAYER NAME

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.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the payer's (identified in loop 1000A) records indicate that another payer has responsibility for processing of the claim, and the claim is not being automatically transferred to that payer.
TR3 Example:
N1✱COR✱NATIONAL INSURANCE COMPANY✱XV✱7777777777~
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
COR
Corrected Name
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Corrected Priority Payer Name
Situational
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
SITUATIONAL RULE: Required when N104 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
XV
Standard Unique Health Plan Identifier (HPID)
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Health Plan Identifier (HPID)
Situational
4
67
Identification Code
X 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.
INDUSTRY NAME: Corrected Priority Payer Identification Number
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

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:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a corrected priority payer has been identified in this iteration of Loop 2105 N1 Corrected Priority Payer Name Segment AND the name or ID of the other subscriber for this payer 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✱1✱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 identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Situational
3
1035
Name Last or Organization Name
X 1
AN
1/80
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), NM103 is present 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
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 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
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
Use when NM102 = 2 and the Federal Taxpayer's Identifier is the primary identifier.
MI
Member Identification Number
Use when indicating the subscriber's identification number as assigned by the payer. (For example, Insureds ID, Subscribers ID, Health Insurance Claim Number (HIC), etc.).
Situational
9
67
Identification Code
X 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
X 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/80

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 claim or
- dental claim or
- institutional claim priced at the service line level

OR

Required when 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).

OR

In the case of pharmacy claims, refer to the NCPDP X12N 835 Payment Reference Guide.
If not required by this implementation guide, do not send.
TR3 Notes:
  1. 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 RAS adjustment to the per diem is appropriate (e.g., RAS*25*CO*78~) and may be sent at the sender's discretion rather than including every service line. See sections 1.10.2.4.1 and 1.10.2.4.6 for additional information.
  2. See section 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✱✱1~SVC✱HC:99214✱100✱80✱✱1✱RA:992~SVC✱RA:00000✱100✱0✱✱1~SVC✱HC:26010:F5✱100✱80✱✱1✱RA:26010:5~
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 Healthcare Common Procedure 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.
  9. C003-09 modifies the value in C003-02 and C003-08.
  10. C003-10 modifies the value in C003-02 and C003-08.
  11. C003-11 modifies the value in C003-02 and C003-08.
  12. C003-12 modifies the value in C003-02 and C003-08.
  1. This is the adjudicated medical procedure information.
  2. This code is a composite data structure.
  3. SVC01-02 through SVC01-06 and SVC01-09 through SVC01-12 are not intended to be validated against any code list when the qualifier in SVC01-01 is RA as they reference invalid or unrecognized codes.
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-01 qualifies the value in SVC01-02, SVC01-04, SVC01-05, SVC01-06, SVC01-09, SVC01-10, SVC01-11, SVC01-12.
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
Healthcare Common Procedure Coding System (HCPCS) Codes
Use when reporting HCPCS or CPT codes. AMA's CPT codes are level 1 HCPCS codes.
CODE SOURCE: 130: Healthcare Common Procedure Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Rate Code
Use when reporting the Skilled Nursing Facility Group Rate Code or the Home Health Agency Outpatient Prospective Payment System Rate Code.
CODE SOURCE: 716: Health Insurance Prospective Payment System (HIPPS) Rate Code
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
RA
Return Code
Use when an invalid or unrecognized code was submitted on the claim and used for adjudication. Refer to section 1.10.2.14.1 for information on reporting invalid or unrecognized procedure information.
ZZ
Mutually Defined
Use when reporting the Device Identifier of Unique Device Identifier.

Prior to the mandated implementation date for the Unique Device Identifier, willing trading partners may agree to follow an early implementation approach.

Code Source: FDA Global Unique Device Identifier Database (GUDID) http://accessgudid.nlm.nih.gov/
Available from:
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894
Required
1-2
234
Product/Service ID
M 1
AN
1/80
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-01.
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/80
Situational
1-9
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 fifth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-10
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 sixth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-11
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 seventh procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
1-12
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 an eighth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Required
2
782
Monetary Amount
O 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. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
  4. See section 1.10.2.14.2 for usage information when service lines are split.
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
  1. 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 RAS segments of this loop. See 1.10.2.1, Financial Balancing, for additional information.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
4
234
Product/Service ID
O 1
AN
1/80
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
This element is not used when the original claim and adjudication only reference an NUBC revenue code. In that situation, the NUBC Revenue Code is supplied in SVC01.
Required
5
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: SVC05 is the paid units of service.
INDUSTRY NAME: Units of Service Paid Count
See Section 1.10.2.4.2 Claim/Service Adjustment Information Segment for Units of Service balancing requirements.
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.
  9. C003-09 modifies the value in C003-02 and C003-08.
  10. C003-10 modifies the value in C003-02 and C003-08.
  11. C003-11 modifies the value in C003-02 and C003-08.
  12. C003-12 modifies the value in C003-02 and C003-08.
SITUATIONAL RULE: Required when the adjudicated procedure code and/or modifier code(s) / modifier order provided in SVC01 is different from the submitted procedure code and/or modifier code(s) / modifier order from the 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.
  3. SVC06-02 through SVC06-06 and SVC06-09 through SVC06-12 are intended to convey the originally submitted service, and are not intended to be validated when the qualifier in SVC06-01 is RA.
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-01 qualifies the value in SVC06-02, SVC06-04, SVC06-05, SVC06-06, SVC06-07, SVC06-09, SVC06-10, SVC06-11, SVC06-12.
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
Healthcare Common Procedure Coding System (HCPCS) Codes
Use when reporting HCPCS or CPT codes. AMA's CPT codes are level 1 HCPCS codes.
CODE SOURCE: 130: Healthcare Common Procedure Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Rate Code
Use when reporting the Skilled Nursing Facility Group Rate Code or the Home Health Agency Outpatient Prospective Payment System Rate Code.
CODE SOURCE: 716: Health Insurance Prospective Payment System (HIPPS) Rate Code
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
RA
Return Code
Use when an invalid or unrecognized procedure code was submitted on the claim. Refer to section 1.10.2.14.1 for information on reporting invalid or unrecognized procedure information.
ZZ
Mutually Defined
Use when reporting the Device Identifier of Unique Device Identifier.

Prior to the mandated implementation date for the Unique Device Identifier, willing trading partners may agree to follow an early implementation approach.

Code Source: FDA Global Unique Device Identifier Database (GUDID) http://accessgudid.nlm.nih.gov/
Available from:
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894
Required
6-2
234
Product/Service ID
M 1
AN
1/80
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/80
Situational
6-9
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 fifth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-10
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 sixth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-11
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 seventh procedure code modifier applies to this service. If not required by this implementation guide, do not send.
Situational
6-12
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 an eighth procedure code modifier applies to this service. If not required by this implementation guide, do not send.
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
  1. See Section 1.10.2.4.2 Claim/Service Adjustment Information Segment for Units of Service balancing requirements.
  2. See section 1.10.2.14.2 for usage information when service lines are split.

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 Loop ID 2100 Claim Statement Period Start or Claim Statement Period End are not supplied, or the service dates are not the same as reported at the claim level, and CLP02 does not equal 25 (Predetermination). 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 predetermination claims when the CLP02 value is 25 - Predetermination Pricing Only - No Payment, no dates are supported at either claim or service level.
  7. When payment is being made in advance of services, the use of future dates is allowed.
TR3 Example:
DTM✱472✱20221031~
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
Use when reporting the beginning of multi-day services. When used, an additional DTM with qualifier 151 must be sent, and the dates in each cannot be the same.
151
Service Period End
Use when reporting the end of multi-day services. When used, an additional DTM with qualifier 150 must be sent, and the dates in each cannot be the same.
472
Service
Use when reporting a single day service. When used, no additional DTMs are allowed for this service.
Required
2
373
Date
X 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
X 1
TM
4/8
Not Used
4
623
Time Code
O 1
ID
2
Not Used
5
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6
1251
Date Time Period
X 1
AN
1/35

RAS - SERVICE ADJUSTMENT INFORMATION

X12 Name:
Reason Adjustment
X12 Purpose:
To supply Claim Adjustment Reason Codes and amounts as needed for an entire claim or for a particular service within the claim being paid
X12 Comments:
Adjustment information is intended to help the provider balance the remittance information. Adjustment amounts must 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. Payers must use this RAS segment to report service 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. An example of this level of RAS 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, Financial Balancing, and 1.10.2.4, Claim Adjustment Information and Service Adjustment Information Segment Theory, for additional information.
TR3 Example:
RAS✱125.32✱PR✱1~RAS✱25✱PR✱3~RAS✱200✱CO✱6^7~RAS✱500✱CO✱45:HE:N13✱1~RAS✱1225✱CO✱16:HE:M24^15:HE:N517✱2~RAS✱2225✱CO✱16:HE:M44:M45:M49^146:HE:MA63:MA65~RAS✱2100✱OA✱18:HE:N522:N702~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: RAS01 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. This amount must not be zero (0).
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Required
2
1785
Claim Adjustment Group Code
M 1
AN
1/10
Code identifying the general category of payment adjustment.
Evaluate the usage of group codes in RAS02 based on the following order for their applicability to a set of one or more adjustments: Patient Responsibility, Contractual Obligation, Payer Initiated, Other Adjustments. (Note: This does not mean that the adjustments must be reported in this order.)

See Front Matter Section 1.10.2.4.5, Claim Adjustment Group Code Usage, for additional information.
CODE SOURCE 974: Claim Adjustment Group Codes
Required
3
C058
Adjustment Reason
M 15
To provide a reason and related explanation for a Health Care Claim or Service change in payment versus the original submitted charges
SEMANTIC: Position of data in the repeating composite data element conveys no significance.
X12 COMPOSITE SYNTAX NOTES:
  1. P0203
    If either C05802 or C05803 is present, then the other is required.
  2. C0403
    If C05804 is present, then C05803 is required.
  3. C0504
    If C05805 is present, then C05804 is required.
  4. C0605
    If C05806 is present, then C05805 is required.
  5. C0706
    If C05807 is present, then C05806 is required.
X12 COMPOSITE SEMANTIC NOTES: C05802 qualifies C05803, C05804, C05805, C05806 and C05807.
  1. This composite identifies the reason for the adjustment of the dollar amount identified in RAS01.
  2. More than one iteration of this composite may be provided only when the entire service submitted charge (SVC02) is being adjusted by this RAS segment (RAS01 equals SVC02) and there are multiple adjustment reasons that are each applicable to the full amount in RAS01.

    See 1.10.2.4.2 Claim/Service Adjustment Information Segment for additional information.
Required
3-1
1034
Claim Adjustment Reason Code
M 1
ID
1/5
Code identifying the detailed reason the adjustment was made
INDUSTRY NAME: Adjustment Reason Code
CODE SOURCE 139: Claim Adjustment Reason Code
Situational
3-2
1270
Code List Qualifier Code
X 1
ID
1/3
Code identifying a specific industry code list
COMPOSITE SYNTAX: P0203
SITUATIONAL RULE: Required when a remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
CODE
DEFINITION
HE
Remittance Advice Remark Code
CODE SOURCE: 411: Remittance Advice Remark Code
RM
Insurance Industry Specific Remark Codes
CODE SOURCE: 973: Insurance Industry Specific Remark Codes
RX
National Council for Prescription Drug Programs Reject Codes
CODE SOURCE: 530: National Council for Prescription Drug Programs Reject Codes
Situational
3-3
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: P0203, C0403
SITUATIONAL RULE: Required when a remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-4
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0403, C0504
SITUATIONAL RULE: Required when an additional remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-5
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0504, C0605
SITUATIONAL RULE: Required when an additional remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-6
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0605, C0706
SITUATIONAL RULE: Required when an additional remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
3-7
1271
Industry Code
O 1
AN
1/30
Code indicating a code from a specific industry code list
COMPOSITE SYNTAX: C0706
SITUATIONAL RULE: Required when an additional remark code or National Council for Prescription Drug Programs Reject Code is necessary for the provider to fully understand the adjustment message for the service adjustment reason identified in RAS03-01. If not required by this implementation guide, do not send.
INDUSTRY NAME: Remark Code
Remark codes that include "Alert" in their description are not reported in the RAS segment, but in the LQ segment at the appropriate level.
Situational
4
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: RAS04 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
  1. A positive value decreases the quantity, and a negative value increases the quantity.
  2. See section 1.10.2.4.2 for information about quantity balancing.

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:
2
Situational Rule:
Required when specific reference identifiers are applicable to the claim, used in the adjudication process, or a result of the adjudication process. If not required by this implementation guide, do not send.
TR3 Example:
REF✱E9✱12346789A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
E9
Attachment Code
Use when an Attachment Control Number was assigned by the provider.
LU
Location Number
Use when the specific site of service affected the payment of the claim.
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Service Identifier
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - PAYMENT DETERMINATION METHODOLOGY

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:
4
Situational Rule:
Required for non-pharmacy claims when specific reference identifiers are applicable to the service line, used in the adjudication process, or is a result of the adjudication process. If not required by this implementation guide, do not send.
TR3 Example:
REF✱9V✱TSUR~REF✱APC✱6541~REF✱AFT✱033214~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
1S
Ambulatory Patient Group (APG) Number
9V
Payment Category
Use when reporting payer specific payment determination methodologies identified in REF02. For example, use when reporting various tiers, rates, per diems, or percentage of charge. These are examples and should not be considered the only payment determination methodologies that can be used with this qualifier.
AFT
Fee Schedule Identifier
Use when advising the provider of the contracting entity's agreed upon enumerated fee schedule identifier for the specific fee schedule/contract that was used to adjudicate and derive the allowed amount for the services. If the contracting entity has the fee schedule on their website, the URL must be supplied in the Payer Website Contact Information PER at 1000A loop.
APC
Ambulatory Payment Classification
CODE SOURCE: 468: Ambulatory Payment Classification
RB
Rate code number
Use when reporting the Ambulatory Surgical Center (ASC) rate for Medicare, either 0, 50, 100 or 150%.
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Service Reference Identifier
  1. This is the 'Payment Determination Methodology' identified by the REF01 qualifier used to adjudicate and derive the allowed amount for the service.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 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 on the 837, or Line Item Sequence Number when no Line Item Control Number was submitted. This is utilized by the provider for tracking.
TR3 Example:
REF✱6R✱54321~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
6R
Provider Control Number
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - SERVICE 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:
3
Situational Rule:
Required when the service provider for this service is different than the service 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 identifying the Reference Identification
CODE
DEFINITION
A6
Provider Identifier
Use when reporting a proprietary provider number assigned by the payer identified in the payer name loop (1000A) associated with this claim. This is true regardless of whether the payer is Medicare, Medicaid, a Blue Cross Blue Shield plan, a Commercial plan, or any other health plan.
HPI
Standard Unique Health Identifier for Health Care Providers (NPI)
Use when the provider is a covered entity under the mandate and must enumerate.
CODE SOURCE: 537: National Provider Identifier (NPI)
TJ
Federal Taxpayer's Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 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 RAS segment
AND
The payer has a published enumerated healthcare policy code list available to healthcare providers via a secured or unsecured public website

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 used to determine claim adjudication that cannot be explained by the sole use of a claim adjustment reason code in the RAS segment and Remark Code when appropriate.
  2. The term Healthcare Policy is intended to include Medical Review Policy, Dental Policy Review, Property & 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 identifier will be used to access the Healthcare policy associated with the adjudication decision.
  5. If this segment is used, the PER 1000A Payer Website segment is required to provide a WEB contact point (secured or unsecured) where the provider can access the payer's enumerated, published healthcare policy.
  6. When reversing a claim that was originally reported with a Health Care Policy ID it is not necessary to mirror the original Health Care Policy ID REF segment in the reversal. If a policy changes which does not affect the financial adjudication of a claim, it is not necessary to create a reversal and send a correction.
TR3 Example:
REF✱0K✱L12345678910~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
0K
Policy Form Identifying Number
Required
2
127
Reference Identification
X 1
AN
1/80
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
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF - SERVICE AUTHORIZATION 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:
2
Situational Rule:
Required when a specific reference identifier is applicable to the service line, used in the adjudication process, or is a result of the adjudication process. If not required by this implementation guide, do not send.
TR3 Example:
REF✱BB✱12346789A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
BB
Authorization Number
Use when supplying an authorization number that was assigned during and used by the adjudication process.
G1
Prior Authorization Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Service Line Authorization Number
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

AMT*B6 - SERVICE ALLOWED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Used to report this payer's allowed amount that was used in adjudicating the claim, prior to considering patient responsibility. See section 1.10.2.13 for information on Secondary Payment Reporting. Used to report this payer's allowed amount prior to considering patient responsibility. Report the amount, even when zero (0). The sum of the allowed amounts at the service line must be reported at the claim level (Loop 2100, AMT01=B6). 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 specifying the amount qualifier
CODE
DEFINITION
B6
Allowed - Actual
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Service Allowed Amount
Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
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:
7
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. This segment is used to convey information only. It is not part of the financial balancing of the 835.
  2. Supplemental information reported at the Claim level (2100 loop) AMT Segment is not repeated.
TR3 Example:
AMT✱T✱425~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code specifying the amount qualifier
CODE
DEFINITION
KH
Deduction Amount
Use when reporting a Late Filing Reduction.
T
Tax
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
  1. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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:
5
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✱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
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
X 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
X 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 Codes not associated directly with a Claim Adjustment Reason Code in a Service Adjustment Information (RAS) segment 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:
Remark codes reported in the LQ segment have no direct relationship to any Claim Adjustment Reason Code reported in a RAS segment. These remark codes stand alone and provide a message related to the service as a whole. See section 1.10.2.4 for additional information.
TR3 Example:
LQ✱HE✱MA15~
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
Remittance Advice Remark Code
CODE SOURCE: 411: Remittance Advice Remark Code
RM
Insurance Industry Specific Remark Codes
CODE SOURCE: 973: Insurance Industry Specific Remark Codes
RX
National Council for Prescription Drug Programs Reject Codes
CODE SOURCE: 530: National Council for Prescription Drug Programs Reject Codes
Required
2
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
SEGMENT SYNTAX: C0102
INDUSTRY NAME: Remark Code

TOO - TOOTH INFORMATION

X12 Name:
Tooth Identification
X12 Purpose:
To identify a tooth by number and, if applicable, one or more tooth surfaces
X12 Syntax:
P0102
If either TOO01 or TOO02 is present, then the other is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
32
Situational Rule:
Required when a tooth number, tooth surface, or oral cavity area was used in the adjudication of the service or when a tooth number, tooth surface, or oral cavity area was submitted on the service line. If not required by this implementation guide, do not send.
TR3 Example:
  1. TOO✱JP✱12✱L:O~
  2. TOO✱JO✱10~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1270
Code List Qualifier Code
X 1
ID
1/3
Code identifying a specific industry code list
SEGMENT SYNTAX: P0102
INDUSTRY NAME: Oral Cavity Area/Tooth Qualifier Code
CODE
DEFINITION
JO
International Standard Designation System for Teeth and Areas of the Oral Cavity
Use when reporting areas of the oral cavity; do not use to report individual teeth.
CODE SOURCE: 135: American Dental Association
JP
Universal National Tooth Designation System
Use when reporting individual teeth; do not use when reporting areas of the oral cavity.
CODE SOURCE: 135: American Dental Association
Required
2
1271
Industry Code
X 1
AN
1/30
Code indicating a code from a specific industry code list
SEGMENT SYNTAX: P0102
INDUSTRY NAME: Oral Cavity Area/Tooth Code
Situational
3
C005
Tooth Surface
O 1
To identify one or more tooth surface codes
SITUATIONAL RULE: Required when the tooth surface code was used in the adjudication of the service or was submitted on the service line. If not required by this implementation guide, do not send.
Required
3-1
1369
Tooth Surface Code
M 1
ID
1/2
Code identifying the area of the tooth that was treated
CODE
DEFINITION
B
Buccal
D
Distal
F
Facial
I
Incisal
L
Lingual
M
Mesial
O
Occlusal
Situational
3-2
1369
Tooth Surface Code
O 1
ID
1/2
Code identifying the area of the tooth that was treated
SITUATIONAL RULE: Required when it is necessary to report an additional tooth surface. If not required by this implementation guide, do not send.
Additional tooth surface codes can be carried in TOO03-02 through TOO03-05. The code values are the same as in TOO03-01.
CODE
DEFINITION
B
Buccal
D
Distal
F
Facial
I
Incisal
L
Lingual
M
Mesial
O
Occlusal
Situational
3-3
1369
Tooth Surface Code
O 1
ID
1/2
Code identifying the area of the tooth that was treated
SITUATIONAL RULE: Required when it is necessary to report an additional tooth surface. If not required by this implementation guide, do not send.
CODE
DEFINITION
B
Buccal
D
Distal
F
Facial
I
Incisal
L
Lingual
M
Mesial
O
Occlusal
Situational
3-4
1369
Tooth Surface Code
O 1
ID
1/2
Code identifying the area of the tooth that was treated
SITUATIONAL RULE: Required when it is necessary to report an additional tooth surface. If not required by this implementation guide, do not send.
CODE
DEFINITION
B
Buccal
D
Distal
F
Facial
I
Incisal
L
Lingual
M
Mesial
O
Occlusal
Situational
3-5
1369
Tooth Surface Code
O 1
ID
1/2
Code identifying the area of the tooth that was treated
SITUATIONAL RULE: Required when it is necessary to report an additional tooth surface. If not required by this implementation guide, do not send.
CODE
DEFINITION
B
Buccal
D
Distal
F
Facial
I
Incisal
L
Lingual
M
Mesial
O
Occlusal

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 cannot be reported using a RAS segment. 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/80
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 provider is a covered entity under the National Provider Identifier (NPI) mandate, this must be the NPI assigned to the provider.
  2. If the provider is not eligible for or has not received an NPI, this is the provider identifier assigned to the provider by the payer.
  3. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
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.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
  1. Refer to code list for definition and usage instructions.
  2. Code Source 967 - Provider Adjustment Reason Codes
Situational
3-2
127
Reference Identification
O 1
AN
1/80
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
This identifier is used by the receiver in identifying, tracking or reconciling the adjustment. See sections 1.10.2.10 (Capitation and Related Payments), 1.10.2.5 (Advanced Payments and Reconciliation), 1.10.2.12 (Balance Forward Processing), 1.10.2.17 (Overpayment Recovery) and 1.10.2.26 (Funds not Available) 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. Refer to Appendix B.1.1.3 for more information about decimal data elements.
  3. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
5
C042
Adjustment Identifier
X 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB05 is the adjustment information as defined by the payer.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
Refer to code list for definition and usage instructions.
Situational
5-2
127
Reference Identification
O 1
AN
1/80
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
X 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
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
7
C042
Adjustment Identifier
X 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB07 is adjustment information as defined by the payer.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
Refer to code list for definition and usage instructions.
Situational
7-2
127
Reference Identification
O 1
AN
1/80
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
X 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
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
9
C042
Adjustment Identifier
X 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB09 is adjustment information as defined by the payer.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
Refer to code list for definition and usage instructions.
Situational
9-2
127
Reference Identification
O 1
AN
1/80
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
X 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
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
11
C042
Adjustment Identifier
X 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB11 is adjustment information as defined by the payer.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
Refer to code list for definition and usage instructions.
Situational
11-2
127
Reference Identification
O 1
AN
1/80
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
X 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
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
Situational
13
C042
Adjustment Identifier
X 1
To provide the category and identifying reference information for an adjustment
SEMANTIC: PLB13 is adjustment information as defined by the payer.
X12 COMPOSITE SEMANTIC NOTES: C042-01 identifies the reason for the credit or debit adjustment. See Code Source 967.
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
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Provider Adjustment Code
Refer to code list for definition and usage instructions.
Situational
13-2
127
Reference Identification
O 1
AN
1/80
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
X 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
  1. This is the adjustment amount for the preceding adjustment reason.
  2. Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.

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✱1230✱0002~
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 Number in ST02 and SE02 must be identical.

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
The Value in IEA02 must be identical to the value in ISA13.
logo

835 Health Care Claim Payment/Advice (008020X322)

SEPTEMBER 2021

Copyright © 2008-21, X12 Incorporated, Format © 2008-21 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

All rights reserved.

Abstract

The Health Care Claim Payment/Advice Implementation Guide describes the use of the X12 Health Care Claim Payment/Advice (835) transaction set for the following business usages:

  • Make payment on a health care claim
  • Send an Explanation of Benefits (EOB) remittance advice
  • Make payment and send an EOB in the same transaction

Preface

X12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners.

As X12 does not define transport requirements, trading partners define their specific transport requirements separately.

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 to facilitate consistent implementation 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 the X12 Health Care Claim Payment/Advice (835). The 835 also may contain information about future remittances that are to be paid when specified services are completed. 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, pharmacies 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.

NOTE:
NCPDP specifications providing specific usage with retail pharmacy industry transactions are available at: https://www.ncpdp.org/.

1.2 Version Information

This implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020).

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

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.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 (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.)

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 was based on requirements for batch mode and real-time mode. Willing trading partners may use batch or real-time mode.

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. The 835 also may contain information about future remittances that are to be paid when specified services are completed.

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 Health Care Transaction Flow

Each X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides.

1.4.2 Information Flows

Figure 1.1 - Information Flow, illustrates the flow of information from Payer to Payee directly or through their DFIs. In this diagram, EFT represents EFT via the ACH Network. Information flows for additional payment types are located in Section 1.10.1.2 - Flows (Dollars and Data).

Figure 1.1 - Information Flow

Information Flow

1.5 Business Terminology

To ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org.

1.6 Transaction Acknowledgments

The purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected.

The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems.

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 Provider's Assigned Claim Identifier reported in the claim within the 837 is returned in the 835 transaction for tracking purposes. The Provider's Assigned Claim Identifier is located in the 837 in CLM01. In the 835, the Provider's Assigned Claim Identifier, for example, a patient control number, is in CLP01.

The Health Care Information Status Notification (277) transaction set has multiple implementation conventions to meet different business needs. The Provider's Assigned Claim Identifier that is reported in the 837 Claim is returned in the 277 for tracking purposes. Following are the 277 implementations and their relationship to the 835:

The Health Care Claim Acknowledgment (277CA) is a business application response to a Claim transaction (837). The 277CA acknowledges the payer's acceptance or rejection of submitted claims. Accepted claims are forwarded for further processing. Once the claim adjudication has been finalized, the adjudication results are reported in the Electronic Remittance advice (835).

The Health Care Claim Pending Status Information (277 Pending) is used as a listing of pending claims in a payer's adjudication system. When the 277 Pending transaction is generated in addition to the 835, it provides a more complete accounting of claims within the payer's system. The Provider's Assigned Claim Identifier is returned in the Provider's Assigned Claim Identifier REF (REF02).

The Health Care Claim Status Request and Response (276/277) uses the 277 as a response to a request (276) for claim status information. In this use the 277 Response can provide status on whether a specific claim is pending or finalized in the payer's adjudication system. For finalized claims, the 277 provides basic remittance advice data to indicate on which remittance advice (835) the claim was reported. The 835 provides the actual detail of the payer's adjudication of the claim. The Provider's Assigned Claim Identifier is returned in the Provider's Assigned Claim Identifier REF (REF02).

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 Provider's Assigned Claim 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 Transaction Compliance

There are three types of compliance that may be relevant to a transmitted transaction.

Compliance with implementation guide requirements

Compliance with state and federal regulation

Compliance with trading partner contractual agreements

1.9.1 Transaction Compliance with Implementation Guide Requirements

A transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself.

Should additional clarification of an X12 implementation guide requirement be desired, two options are available.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process.

A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined.

1.9.2 Transaction Compliance with State and Federal Regulations

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 state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities.

X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority.

1.9.3 Transaction Compliance with Contractual Requirements

X12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity.

1.10.1 Overall Data Architecture

NOTE
See Appendix B, X12 Control and Guidance, 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 corresponds to a single payment device. In other words, while an 835 transaction set can include one or more claims, it must be matched to only one payment (e.g. check, EFT, or card payment).

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

835 traveling separate from the dollars in the EFT payment
These transactions move completely separate, one through electronic data interchange (EDI) channels and the other through the ACH banking network. They are reconciled by the provider using a common Trace Segment (TRN) that is found in both the 835 as well as in the Addenda record of the National Automated Clearing House Association (NACHA) transaction, Corporate Credit or Debit Entry plus Addenda CCD+ file format. The Addenda record is also referenced as record 7 in the CCD+ file format. Sections 1.10.2.2 and 1.10.2.3 describe the business requirements. When separating the 835 from the ACH payment, the only ACH format that is permitted is the CCD+. The TRN segment included in the Addenda record, record 7 field 3, must comply with the 835 TR3 requirements. In addition, since specific trading partners can use characters that are not supported in the addenda record as delimiters in the TRN, it is important that the structural parts of the TRN segment not preclude inclusion in the addenda record. When conveying the TRN segment in the addenda record of the CCD+, the segment MUST use the "*" as the data element separator and the "\" as the segment terminator. This does not require that the 835 use those characters as delimiters. This specification applies ONLY to the addenda record. If a payer supports EFT, they MUST support the CCD+ format and make it available to providers who may prefer to use it.

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.2.6 ERA with Payment by Card

Figure 1.7 - Card Straight-Through Processing via Card Network

Card Straight-Through Processing via Card Network

Figure 1.8 - Virtual Card via Card Network – Payment Notification External to the 835 (Remittance Advice)

Virtual Card via Card Network – Payment Notification External to the 835 (Remittance Advice)

Figure 1.9 - Virtual Card via Card Network – 835 Used for Payment Notification and Remittance Advice

Virtual Card via Card Network – 835 Used for Payment Notification and Remittance Advice

Depending on the contract between the Payee and Payer, card payments can occur in a variety of ways. Fundamentally there are two basic scenarios, Straight-Through Processing & Virtual Card Processing for debit or credit cards (When referring to card payment, debit versus credit relates to how the card itself is associated with the Payer's accounts (refer to Figure 1.7), and is different than the debit and credit concepts in BPR03, which relate to how the money is moving from the Payer's account to the payee) (refer to Figures 1.8 and 1.9).

In a Straight-Through Processing scenario, (refer to Figure 1.7), the Payer issues the instructions for initiating the payment (information including the payment amount in a format agreed upon between the Payer and the Third-Party Processor) to the Payee's Third-Party Processor, which is where the card payment occurs and is transferred across the specific card network (funds are not transferred via the ACH network, but rather through a separate card network). The Processor issues the funds to the Payee's DFI (similar to an EFT payment via the ACH Network), and the reassociation information is sent from the Payee's DFI to the Payee. The Payee would apply for a unique Merchant Identifier (MID) from the Third-Party Processor to Opt In to Straight-Through Processing. Upon agreeing to opt in to the Straight-Through Processing, the Payee and Payer must communicate related registration information in order to facilitate the Straight-Through Processing. A pre-note type process may occur to validate account information, but is not required.

In a Virtual Card Processing scenario, (refer to Figures 1.8 and 1.9), after the Payer issues the payment instructions to the Third-Party Processor, detailed information on the card payment is sent to the Payee (information with the card payment identifier, payment amount, etc.) This information can be sent via mail / email / fax / portal / other, or included within the 835 itself. The Payee then takes the appropriate action either manually via their POS terminal or in an automated fashion to initiate the payment with their DFI. The format in which the Payee receives the payment notification will determine the method required for initiating the payment with the DFI. Automation may depend upon details of the delivery media and requirements of the Payee's DFI, and may not always be feasible.

In the first two scenarios, remittance information is provided to the Payee from the health plan, but this information follows a different path than the card payment, and may flow directly to the Provider or via intermediaries like clearinghouses. In the Virtual Card scenario where the payment information is included in the 835 itself, the remittance information and payment notification flow together to the Payee. An indicator in the 835 (BPR03) reflects the Virtual Card versus Straight-Through Processing option utilized. See Section 1.10.2.3 - Reassociation of Dollars and Data, for a description of reassociation.

1.10.1.3 Electronic Funds Transfer

The EFT Standards Final Rule that became effective January 1, 2014, (45 CFR Part 162, "Administrative Simplification: Adoption of Operating Rules for Health Care Electronic Funds Transfers (EFTs) and Remittance Advice Transactions; Final Rule") gives providers the ability to require health plans to deliver electronic payments through EFT in the CCD+ format via the ACH network. Health Plans MUST provide an EFT payment in the CCD+ format via the ACH Network if the provider requests it over other forms of payment, including card payments. Payments via card do not meet this EFT requirement because they are not processed through the ACH network in the CCD+ format. The Rule does not, however, explicitly preclude the use of card payments or other forms of payment when willing trading partners agree to exchange payments via a method other than the HIPAA-mandated EFT standard.

Providers need to know that payers may not:

  • Refuse to conduct a transaction as a standard transaction
  • Delay a transaction or otherwise adversely affect the provider on the grounds that the transaction is a standard
  • Charge an excessive fee or otherwise give providers incentives to use an alternative payment method to EFT via the ACH Network (45 CFR Part 162.925)

Providers who choose not to use the ACH Network may continue to receive payments by check, Fedwire, and other payment networks like card networks.

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 through the ACH network. The information required for the funds transfer is communicated electronically.

Specific EFT formats can carry varying degrees of remittance information through the banking industry's ACH Network. When the remittance information accompanying the EFT goes through the ACH Network, the payee receives direct information about the details regarding 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 Trace Number 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 (also known as "Corporate Credit or Debit Entry Plus Addenda) (CCD+) ACH format is specified in the Financial Segment, BPR, using the code value CCP in BPR05.Then the entire TRN segment from the 835 is included 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 Card Payments in the 835

Section 1.10.1.3 - Electronic Funds Transfer describes the payment types that are mandated and available within the current (at the time of publication of the TR3) EFT Standard Final Rule. Another payment type that is available within the current EFT Standard Final Rule when agreed upon in advance by all trading partners is a card payment type.

For Providers that choose to receive card payments, there are two types of Cards: those that issue funds to the Payee's account (called credits) and those that deduct funds from the Payer's account (called debits). There are multiple variations of Card PRODUCTS from these two card types, which can include Credit Cards, Debit Cards, Virtual Cards, PCards, and others. Payments made via card do not use the ACH network used by other EFT payments; separate card payment networks are used for these payments. Processes for actually conducting the card payments will vary per card processor, including processes to opt-out or opt-in to card processing, and are not standardized as are the EFT payments made via the ACH network.

The card process:

When payment is made via card, the process is similar to that of EFT. The Payer initiates the payment, but it is initiated through a Third-Party Processor rather than the Payer's DFI. The Third-Party Processor funds the payment to the Payee's DFI. A payment notification is delivered to the Provider, and the funds are deposited into a bank account. In some cases, Payers will fax, email, or mail the payment notification details to the Provider, including all of the card information like card payment identifier, expiration date, payment amount, and security code. The Provider will then manually process the payment through their existing POS terminal. Providers may also have the option for a "Buyer Initiated" or "Straight-Through" Processing option, with card payments going through a Third-Party Processor to their card accounts without the Payee having to re-enter the card data, eliminating security concerns. Straight-Through Processing is identified in BPR03 using qualifier "C", meaning credit. This indicates that the Payee's account is being directly credited with the payment from the Payer's account. The 835 can also be used as the payment notification, by including the card security code and expiration date along with the remittance advice information. Payment notification using the 835 or an external means like fax or mail that requires posting to the card processor by the Payee is indicated in BPR03 using qualifier "D", meaning debit. This indicates that the Payee is to instruct their processor to take the funds from the Payer's account. Fees are incurred for the card transactions; however, they are typically "bulked" and assessed monthly, not per transaction. These fees normally include a per transaction component as well as a percentage of the payment component. Section 1.10.1.2.6 - ERA with Payment by Card describes the process flow for card payments.

Reassociating the Card Payment to the 835:

See Section 1.10.2.3 - Reassociation of Dollars and Data for information on reassociating card payments to their corresponding 835.

Card Payment Fees:

There are fees associated with all types of electronic funds transfer, and these vary per payment type. Fees associated with card payments will vary based upon the agreement between the Payee and the Third-Party Processor. These fees, along with how the fees will be assessed should be clearly outlined in the written agreement between the Payee and Third-Party Processor. Any fees associated with the card payment should be reflected on the processor statement and will not be reflected in the 835. Any available RARCs that reference card payments or fees must be included in the 835 (e.g. N774 Alert: Refer to your Third Party Processor Agreement for specific information on fees associated with this payment type."). (Note - this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.)

1.10.1.4.1 PCI Compliance For Card Payment Information in the 835

Given that virtual credit cards are non-physical, it is almost impossible to clone them, which makes it extremely secure for all online transactions. Including Virtual Card payment information in the 835 does, however, raise questions about the need for Payment Card Industry (PCI) compliance for the 835.

A key definition regarding credit and debit cards is the "Primary Account Number" or PAN. The full Primary Account Number (PAN) is the 14, 15 or 16 digit number that appears on the primary account holder's (payer's) "master" credit card. The primary account holder (payer) has a "master" card that has their PAN; but this is different than any account number appearing on a virtual card. The actual PAN is never included or even referenced within a virtual card that is sent for payment.

The virtual card will include a number that LOOKS like a card number; however, this is NOT the PAN. The virtual card number is temporary and will only be valid for a fixed period of time, whereas the PAN is the primary and permanent, main account number for the account holder (payer). The virtual card has to have some of the same features as a "real" card (like a card number) so that it can process through card terminals and platforms; however, each virtual card can have its own parameters and controls built around its use that are set by the card issuer (thus faxes may contain statements like "Please process this payment in full for the exact amount indicated above").

The PCI Security Standards Council (SSC) defines 'cardholder data' as the full Primary Account Number (PAN) or the full PAN along with any of the following elements (Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS) definition of terms. Glossary of Terms, Abbreviations, and Acronyms Version 2.0 October 2010):

  • Cardholder name
  • Expiration date
  • Service code

In addition, single use virtual cards do not require PCI DSS be applied because these cards are inactive/disabled after use therefore the PANS no longer pose fraud risk to the payment system. Virtual Card numbers which are MasterCard corporate cards require no obligation by the corporate card client to provide validation that corporate card data is protected in accordance with PCI DSS. The corporate card client is not obligated to secure their data as it is their cardholder data and their risk to assume and manage. As a result, MasterCard does not require corporate card entities to validate PCI DSS compliance for its commercial cards but highly recommends taking appropriate steps to secure those account numbers (The Mastercard Site Data Protection (SDP) Program Frequently Asked Questions, March 22, 2012).

Because single use Virtual cards do not use the PAN and the cards are inactive / disabled after use, they are excluded from the PCI Data Security Standard (DSS) requirements.

1.10.1.5 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.10 - 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.10 - 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. See Section 1.10.2.1 - Financial 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 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 835 structure consists of three levels. 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.11 - 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 X12 Health Care Claim Status Notification Transaction Set (277). Refer to Section 1.4 - Business Usage to determine which TR3 implementation to utilize for Claim Status for pending claims.

1.10.2.1 Financial 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 Information (RAS) and Service Adjustment Information (RAS), 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 Information and Service Adjustment Information Segment Theory, for more details.

Forced balancing (addition of a claim, service, or provider-level adjustment that accomplishes financial balancing at the claim, service, or transaction level without providing an explicit, valid reason for the related adjustment amount that is meaningful to the provider) is not allowed under any conditions. Situations that cause out of balance conditions must be resolved at the source rather than through forced balancing. All adjustment codes used must be relevant to the adjudication of the claim. Inappropriate use of adjustment codes strictly for the purpose of balancing is not allowed.

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.12 - Service Line Balancing Segments

Service Line Balancing Segments

Although the service payment information is optional, it is REQUIRED for all service lines in a

  • professional claim or
  • dental claim or
  • outpatient institutional claim priced at the service line level
    OR
    Required when 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).

When service level reporting is required, all adjustments related to a specific service line, including patient responsibility, must be reported on that individual service line. The submitted service charge minus the sum of all monetary adjustments must equal the amount paid for that service line.

The exceptions to this rule are:

  • Property and Casualty claims may have state regulations impacting whether some patient responsibility amounts are to be reported at the claim level or service level (e.g. Deductible, Co-Pay, Co-insurance, and Benefits Exhausted/Maximum). In this situation, patient responsibility amounts may be reported at either the claim or service level.
  • Dental / Vision utilization payments, not specific to any submitted service line, may have utilization adjustments reported at the claim level.
  • If the subsequent payer received COB payment information at the claim level, they can respond at either the claim or service line level. The preferred method is to report at the line level.

For Service Line balancing, the following formula applies:

SVC02 (submitted charge for this service line) minus the sum of RAS01 values (adjustment amount applied to this service line) equals SVC03 (paid amount for this service line)
See Section 1.10.2.1.4 Positive/Negative Adjustments and Balancing

1.10.2.1.2. Claim Balancing

Figure 1.13 - 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:

CLP03 (total submitted charge for the claim) minus the sum of RAS01 values (adjustment amount applied to this claim) equals CLP04 (paid amount for this claim)

See Section 1.10.2.1.4 - Positive / Negative Adjustments and Balancing

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

CLP03 (total submitted charge for the claim) minus the sum of RAS01 values (Claim Adjustment Information Segment and/or Service Adjustment Information Segment adjustment amounts applied to this claim) equals CLP04 (paid amount for this claim)

See Section 1.10.2.1.4 - Positive / Negative Adjustments and Balancing

NOTES
When balancing claims that include the Service Payment Information loop, all Claim Adjustment and Service Adjustment monetary amounts are included in the balancing equation. When balancing claims that do not include the Service payment Information loop, all Claim Adjustment monetary amounts are included in the balancing equation.

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 RAS segment using an "Other Adjustment" Claim Adjustment Group code (RAS02), a Claim Adjustment Reason code (RAS03) of 133 and the full dollar amount for the service in RAS01. 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.14 - 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.

Sum of all CLP04 (total of all claim amounts included in this transaction set) minus the sum of PLB04, 06, 08, 10, 12, and 14 (provider level adjustment(s) made to the claim payment) equals BPR02 (total payment amount)

See Section 1.10.2.1.4 - Positive / Negative Adjustments and Balancing

1.10.2.1.4 Positive / Negative Adjustments and Balancing

Adjustments within the PLB, 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.

1.10.2.2 Remittance Tracking

Figure 1.15 - Remittance Tracking Segments

Remittance Tracking Segments

The Reassociation Trace Number 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 card payments, TRN02 is the card number or card payment identifier.
  • 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, card, 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 Trace Number Segment, TRN02, and the Payer Identifier, TRN03.The trace number in conjunction with the Payer Identifier provides a unique number that identifies the transaction.

Remittance Advice data is sent in the 835; therefore, there is a need to reassociate the remittance advice to the payment. Reassociation may be accomplished by several methods, depending on the payment method being utilized.

When sending an ACH payment, the NACHA CCD+ format is mandated for use when requested. Using this method, the Reassociation Trace Number Segment in its entirety is the only value included in the "Payment Related Information" field of the CCD+ ACH Addenda Record. Note that only specific characters are allowed to be used for delimiters in the "Payment Related Information" field of the CCD+ Addenda Record, so the delimiter may vary from that of the 835, and should be taken into account while reassociating. If the CTX format is used for an EFT payment, reassociation of the payment and 835 is not needed because the 835 travels along with the payment information.

For complete details on reassociation and ACH file formats, contact either your local Value Added Bank (VAB) or NACHA — The Electronic Payments Association.

In the case of a payment received by paper check, the check number is the trace number in TRN02, and the Payer Identifier 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 Payer Identifier received in TRN03. This information should be gathered when the transaction is implemented with the Payer.

When payment is made via card, the 835 corresponding to the card payment must contain the information necessary to reassociate the 835 to the card payment notification (when the 835 itself is not the card payment notification). The BPR04 value must correlate to the type of card used. BPR02 must reflect the actual payment amount. BPR03 reflects the card product (Virtual or other card versus Straight-Through Processing) — "C" indicates Straight-Through Processing, and "D" indicates Virtual or other card. BPR16 must reflect the Effective Entry Date of the card payment when Straight-Through Processing is used, and the date that funds are available for any other card processing method. TRN02 must include the virtual card number or card payment identifier. These values will be reflected on the card payment notification, which can be automatically reassociated to the 835 when the card payment notification is received electronically, or manually when the notification is received in a paper format (just as paper checks must be manually reassociated with an 835).

If the 835 is used as the payment notification in addition to the remittance advice, then a Table 1 REF must be included to reflect the card security code (if applicable), and a Table 1 DTM must be included with the Expiration Date of the card (if applicable).

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 Trace Number Segment (TRN) in its entirety is the only value included in field 3 of the CCD+ ACH 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 a Provider Adjustment Code indicating "Reissued Payment" 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.1 CAS to RAS Upgrade

Since prior implementation guides used the CAS segment for adjustments at both the claim and service levels, there will be a need to convert to the RAS segment when implementing this guide's instructions.

The CAS segment supported up to six separate adjustments (amount, CARC and quantity) consistent with a single Claim Adjustment Group Code. The RAS segment supports only one adjustment per segment. As a result, converting from the CAS to the RAS will involve the creation of more RAS segments than the number of CAS segments in prior versions. There is a one to one relationship between a CAS amount, CARC and quantity trio and a single RAS segment.

In prior versions that used the CAS segment, Remark Codes that were related to an adjustment were reported in the MIA or MOA segment at the claim level or the LQ segment at the service level. With the RAS segment, the Remark Codes must now be associated directly with the related CARC, when a relationship to a specific CARC exists. This change requires a modification from a business perspective, and is not a simple mapping change. This change clarifies the fact that Remark Codes serve multiple functions within the 835 transaction. Sometimes they are related to a CARC and are a critical part of the message of a specific RAS segment/CARC. Other times they have no correlation to the RAS segment and provide additional information that is part of the general claim or service adjudication message.

Whenever a Remark Code is associated with a CARC or a CARC requires the presence of a Remark Code, the Remark Code must be reported in the RAS03 composite data structure with the CARC. The RAS segment supports up to five Remark Codes associated with a single CARC code. When multiple Remark Codes are necessary to provide a complete message related to a CARC, they must be provided with the CARC in the same RAS03 composite element. Remark Codes that are not associated with a specific CARC must still be reported in the appropriate 2100 or 2110 LQ segment.

1.10.2.4.2 Claim/Service Adjustment Information Segment

The Claim Adjustment Information and Service Adjustment Information Segments (2100 and 2110 loop RAS segment) provide the amounts, reasons, and quantities of any adjustments that the payer made to the original submitted charge and to the units related to the claim or service(s). The summation of the adjustments at the claim and service level is the total adjustment for the entire claim. Adjustments reported at the Service level (2110 loop) are not repeated at the claim level (2100 loop) and vice versa. Note — the RAS segment at the 2100 and 2110 loops in this guide replaces the usage of the CAS segment at those loops in prior implementation guides.

Figure 1.16 - Claim and Service Adjustment Segments

Claim and Service Adjustment Segments

Each RAS segment identifies a single adjustment to the original submitted charge for the claim/service by:

Amount — this is the amount of the adjustment. A positive value reduces the payment, a negative value increases the payment. This is required, and must not be zero.

Claim Adjustment Group Code — identifies and categorizes the general class of the adjustment and any related responsibility from a set of codes in a standard external code list. This is required.

Claim Adjustment Reason Code (CARC) — identifies the reason for the adjustment using a code from a standard external code list. At least one is required.

Additional CARCs can be provided for a single adjustment amount when multiple adjustment reasons apply, and only when the adjustment amount represents the entire claim/service charge amount. When multiple CARCs are reported in a single RAS segment, the RAS01 must equal the total submitted charge for the claim/service and each CARC must independently represent the full dollar amount reported in RAS01 (i.e. each CARC does not comprise a portion of RAS01, each CARC applies to the entire RAS01 amount). Providing multiple CARCs for an adjustment amount that represents the entire claim/service charge will prevent repetitive claim submissions and subsequent adjustment notifications.

In the following example, the total submitted charge amount is $200 and the RAS looks like:

RAS*200*CO*39^61~

CARCs 39 (Services denied at the time authorization/pre-certification was requested (Note-this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.)) and 61 (Adjusted for failure to obtain second surgical opinion (Note-this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.)) both apply to the full $200 charge. CARC 39 does not represent a portion of the $200 and 61 to the remaining portion. Both CARCs apply to the entire $200.

Each unique adjustment amount requires its own RAS segment. If at any time, a CARC applies to only a portion of the total submitted charge for the claim/service, a separate RAS is required.

Remark Code — identifies additional information related specifically to a CARC that further clarifies the adjustment reason. Up to five Remark Codes can be associated with each CARC. The Remark Codes can only be from one of the standard external code lists listed in the RAS segment detail in the 2100 and 2110 loops, including the Remittance Advice Remark Code (RARC) external code list, the Insurance Industry Specific Remark Code (IISRC) external code list, or the standard NCPDP Reject Codes external code list (only used in the 2110 loop). At the claim level, the only applicable Remark Code lists are RARCs and IISRCs. At the service level, remark codes can be RARCs, IISRCs, or NCPDP Reject Codes.

Remark Codes are situational and are required when they are necessary for the provider to fully understand the adjustment message for the claim adjustment reason. Note — when a CARC description requires the presence of a Remark Code to complete the message, that Remark Code must be provided in the related RAS segment directly associated with the CARC.

Certain informational Remark Codes can be used without any association to a specific CARC, at either the claim or service level (some of these remark codes begin with the word "ALERT"). Remark codes used without any association to a specific CARC are included in the claim level (2100 loop) or service level (2110 loop) Health Care Remark Codes (LQ) segment.

Adjustment Quantity — this is the non-covered days (2100 loop) or non-covered units of service (2110 loop) when the adjustment amount is related to a reduction in the related units. The Adjustment Quantity is situational and is required when the adjustment is related to non-covered days or units of service. The Service level (2110 loop) includes a balancing requirement related to the Units of service - the Submitted Units of Service (SVC07) minus the Adjustment Quantities (2110 RAS04 elements) equals the Paid Units of Service (SVC05).

Example:

CLP*1234567890*1*1000*350*250**9012345678~

SVC*HC:99255*1000*350**3**5~

RAS*50*PR*1~

RAS*200*PR*2~

RAS*200*CO*45~

RAS*100*CO*B1*1~

RAS*100*CO*222*1~

The Claim Adjustment Reason Code and the five iterations of the Remark Code are part of a composite data structure. The composite can repeat up to fifteen times per RAS segment. More than one iteration of this composite (CARC and Remark Codes) per RAS segment may only be provided when there are multiple adjustment reasons (CARC/Remark Codes) that are each applicable to the full amount of the adjustment in RAS01, and that amount represents the full charge for the claim (CLP03 when the RAS is in loop 2100) or service (SVC02 when the RAS is in loop 2110) as applicable.

Remark Codes within a specific iteration of the composite are directly related to the CARC in that iteration of the composite. See the RAS segment detail in the 2100 and 2110 loops for complete structural information.

Only use the Claim/Service Adjustment Segments if needed. Never use the RAS segment to report a zero amount in RAS01. Remark Codes not directly related to a CARC are to be reported in the LQ segment.

1.10.2.4.3 Claim Adjustment Reason Code (CARC) Usage

A standardized list of Claim Adjustment Reason Codes are used in the Claim Adjustment and Service Adjustment Segments. See Appendix A, External Code Sources, for the list location, and refer to this list for the most current valid codes and descriptions.

To facilitate and expedite reason code maintenance, the list was established external to the X12 standards. X12 owns the CARC list and maintains a committee of Industry representatives to maintain the list, which is updated 3 times a year. As with any external code list, maintenance requests should be addressed to the responsible entity. Review X12 processes for direction on submitting maintenance requests.

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.

Specific usage related to the CARCs and remark codes are documented externally in the X12 Type 2 Technical Report "Code Value Usage in Health Care Claim Payment and Subsequent Claims" (CARC/RARC TR2). The document can be accessed at: http://store.x12.org/store. Since the CARC list is maintained by a committee that meets and can make changes (additions, description changes or deletions) three times a year, the CARC/RARC TR2 document will be updated in conjunction with the same schedule. Directions for requesting changes to the code mapping can be found in the CARC/RARC TR2.

Code usage is based upon the adjudication date, not the date of service in the claim. When the codes become inactive from the time that the primary payer paid and the time that any secondary claim is created, the provider will use the code that was sent originally in the 835 in the secondary claim (see the FAQs associated with the CARC list at www.wpc-edi.com for information on stop dates for CARCs).

CARC with Required Remark Codes
Certain CARCs require the use of associated Remark Codes (as indicated in the CARC description). At the claim level, only RARCs or Insurance Industry Specific Remark Codes (IISRCs) can be reported. At the service level, the CARC Remark Code requirements can be met with NCPDP Reject Codes for retail pharmacy claims, or can be met with RARCs or IISRCs for all health care claims. For those CARCs whose descriptions indicate that a Remark Code is required, usage of the CARCs without at least one allowed associated Remark Code at the same level (2100 or 2110 loop) would be outside of standard usage. For situations that are covered by the CAQH CORE Rule 360 business scenarios (or any future operating rule requirements), the code combination must be one that is part of CAQH CORE Rule 360. For other business scenarios, the available code combinations are documented in the CARC/RARC TR2. Other code combinations are outside of standard usage.

CARC and Remark Code Associations
The majority of CARCs don't require usage of remark codes to complete the message. When service level CARC codes that don't require remark codes are used and the message is incomplete without the remark code, then the remark code is required to be sent at the service level. The remark codes can be NCPDP Reject Codes for retail pharmacy drug claims, or RARCs or IISRCs for all other health care claims.

For situations that are covered by the CAQH CORE Rule 360 business scenarios (or any future operating rule requirements), the code combination must be one that is part of CAQH CORE Rule 360. For other business scenarios, the available code combinations are documented in the CARC/RARC TR2. Other code combinations are outside of standard usage.

The RAS segment allows only one type of Remark Code to be included with each CARC, so if a mixture of RARCs and IISRCs are needed to complete the message for the CARC, codes from one list are reported in the RAS and codes from the other list are reported in the LQ segment. It is recommended by the authors of this TR3 to include the codes from the code list that have the most significant part of the message in the RAS segment.

Generic versus Specific CARC
While the CARC codes are intended to be generic, there are many instances where multiple codes have similar but distinct meanings. In order to accurately convey the message of the adjudication to the provider, the appropriate CARCs must be used at all times. Usage of the CARCs without considering which one is the most accurate fit for a given situation as identified by the CARC/RARC TR2 would be outside of standard usage.

Within this guide, whenever a CARC code is listed with its definition, that is the current definition as of development of the guide. When descriptions are listed in the TR3, a disclaimer will also be included stating "Note-this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.)"

1.10.2.4.4 Remark Codes

Standardized lists of Remark Codes are used to convey information about the remittance processing and provide supplemental explanation for the adjustment already described by the CARCs. The Remittance Advice Remark Codes provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code (CARC) or convey information about remittance processing. The Insurance Industry Specific Remark Codes (IISRCs) provide information that may be more specific to a certain industry segment (e.g. dental).

See Appendix A, External Code Sources, for the list locations, and refer to these lists for the most current valid codes and descriptions. The Remittance Advice Remark Codes (RARC) list is maintained by The Center for Medicare and Medicaid Services (CMS) and updated 3 times a year. The Insurance Industry Specific Remark Code list is maintained by X12. Maintenance requests for both lists are submitted via the online conference at http://www.wpc-edi.com/.

Certain informational Remark Codes can be used without any association to a specific CARC, at either the claim or service level (some of these remark codes begin with the word "ALERT"). The following sections establish requirements for usage of RARCs when there is no association with a specific CARC code implied or applicable.

1.10.2.4.4.1 Claim Level

At the claim level, the only applicable Remark Code lists are RARCs and IISRCs. Certain RARCs or IISRCs can be used without any association to a specific CARC, and are applicable at the claim level (2100 loop) of the 835, in the Health Care Remark Codes (LQ) segment. The specific requirements for usage of Remark Codes without association to CARCs at the claim level (2100 loop) in the LQ segment can be found in the CARC/RARC TR2. Usage of the Remark Codes at the claim level not specified in the CARC/RARC TR2 without an association with a specific CARC is prohibited.

1.10.2.4.4.2 Service Level

At the service level, remark codes can be RARCs, IISRCs, or NCPDP Reject Codes. Certain remark codes can be used without any association to a specific CARC, and are only applicable at the service line level (2110 loop) of the 835, in the Health Care Remark Codes (LQ) segment. The specific requirements for usage of remark codes without association to CARCs at the service level (2110 loop) in the LQ segment can be found in the CARC/RARC TR2. Usage of the remark codes at the service level not specified in the site, and without an association with a specific CARC, is prohibited. The specific requirements for usage of NCPDP Reject Codes on retail pharmacy claims, without association to CARCs, at the service level (2110 loop) in the LQ segment can be found in the Code Source 530: National Council for Prescription Drug Programs Reject Codes.

1.10.2.4.4.3 Reversals

Remark codes used in reversals must reflect the original codes used in the original remittance advice, including using the appropriate Reversal and Correction Alert Remark Code in the LQ segment to indicate the reason for the reversal and correction.

Reversals of prior claim adjudications must report the original codes used in the remittance advice being reversed. An additional remark code identifying the reason for the reversal is also included in the 2100 loop LQ segment (2110 loop LQ segment for pharmacy). New adjudication information will use any corrected or new codes available at the time the report is created.

1.10.2.4.5 Claim Adjustment Group Code Usage

A standardized list of Claim Adjustment Group Codes is used to identify the type of adjustment being made. (Appendix A, External Code Sources, for the list location.) CARCs describe the reason for the type of adjustment being made. When posting payment information it is important to understand the entire message being sent by evaluating Group Codes, CARCs and Remark Codes in combination.

There is no requirement for a specific order for reporting the groups within the 835. All RAS segments within a specific loop are logically equivalent and the order does not matter.

The following situations describe the only uses for the following types of Claim Adjustment Group Codes:

  • Patient Responsibility
    Group Codes that indicate Patient Responsibility are used in situations where the patient is responsible for the amount being adjusted. Some examples include, but are not limited to: co-payment, co-insurance, deductible, and benefit limitations.
  • Contractual Obligations
    Group Codes that indicate Contractual Obligations are used in the situations below. The amount being adjusted is the responsibility of the provider, it is not the responsibility of the patient.
    • a contract or negotiated fee arrangement exists between the payer and the provider
    • regulatory requirements exist.
    • missing information, billing or coding errors (provider only) and a contract / negotiated fee arrangement/regulatory requirements exist.
  • Payer Initiated Reductions
    Group Codes that indicate Payer Initiated Adjustments are used in the situations below. The payer holds the position that the member should not be responsible for the amount being adjusted; however, ultimate responsibility has not been established.
    • a contract or negotiated fee arrangement does not exist between the payer and the provider
    • regulatory requirements do not exist.
    • missing information, billing or coding errors and a contract/negotiated fee arrangement / regulatory requirements do not exist.
  • Other Adjustments
    Outside of retail pharmacy, Group Codes that indicate Other Adjustments are only used when other group codes do not apply in the situations below. Ultimate responsibility of the amount being adjusted cannot be determined by the payer.
    • explicitly allowed or required by a business section of the implementation guide (for example, when reporting bundling and unbundling), or
    • explicitly included in the CARC code usage requirements expressed within the CARC description itself (for example, the CARC description includes the verbiage "(Use Group Code OA)").

Pharmacy adjustments may utilize an "Other Adjustment" Group Code for CARCs as indicated in the NCPDP specifications that provide specific use with the retail pharmacy industry and the pharmacy transaction. These specifications are at http://www.ncpdp.org.

CARC with Claims Adjustment Group Codes
CARCs are always associated in the 835 with a specific Claim Adjustment Group Code. Usage of the CARCs and associated Claim Adjustment Group Code is included in the CARC/RARC TR2. A combination not listed in the CARC/RARC TR2 would be outside of standard usage.

1.10.2.4.6 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 RAS 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 (PIP) lump sum amount). (Note-this description is as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.) 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 RAS 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*20111231*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***9878768~

PLB*12345*20111231*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*20111231*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 adjudicated 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.2 - , 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 RAS segment with an "Other Adjustment" group code and a reason code of 94 (Processed in Excess of Charges) with a negative dollar amount. From that point, apply all normal RAS 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 (The benefit for this service is included in the payment/allowance for another service/procedure that has already been adjudicated.) and an adjustment amount equal to the submitted charge. The Adjustment Group is either a "Contractual Obligation" or "Payer Initiated" Group Code 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**1234567ABC~
SVC*HC:C*100*50**1*HC:A*1~
RAS*-100*OA*94:HE:M15~
RAS*80*CO*45~
RAS*50*PR*1~
RAS*20*PR*2~
SVC*HC:C*100*0**0*HC:B*1~
RAS*100*CO*97:HE:M15*1~

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, RAS 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. CARC 45, "Charge exceeds fee schedule/maximum allowable or contracted/legislated fee arrangement", is used for the first service that is unbundled, and CARC 97, "The benefit for this service is included in the payment/allowance for another service/procedure that has already been adjudicated. Note: Refer to the 835 Healthcare Policy Identification Segment (loop 2110 Service Payment Information REF), if present. This change effective September 1, 2017: The benefit for this service is included in the payment/allowance for another service/procedure that has already been adjudicated. Usage: Refer to the 835 Healthcare Policy Identification Segment (loop 2110 Service Payment Information REF), if present." is used for the second service line that is unbundled. (Note - these descriptions are as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.).

See Section 1.10.2.4.2 - and Section 1.10.2.14.2 - Service Line Splitting for requirements on balancing units. See the external examples website for additional examples of unbundling that include units.

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

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.2 - Service Line Splitting, for additional information.

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

CLP*123456789*1*72*69*0~
SVC*HC:80049*45*45**1~
SVC*HC:80054*30*30**1~
SVC*HC:82435*0*-6**0*HC:80054*1~
RAS*6*CO*97~

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*6R 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 RAS segments. Use an "Other Adjustment" Claim Adjustment Group Code and a Claim Adjustment Reason Code of 101 (Predetermination: anticipated payment upon completion of services or claim adjudication.) (Note-this description is as of the publication of this book. Please refer to http://www.wpc-edi.com for the most current description.). 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 $1100.00. The payer determines that, if the claim is to be paid, the adjustments shown in Table 1.1 - Example Adjustments, are to be applied.

Table 1.1 - Example Adjustments

Adjustment Amount Claim Adjustment Reason Code
Deductible $50.00 Code 1
Coinsurance $200.00 Code 2
Exceeded the fee schedule $200.00 Code 45
Non-Covered Visits $100.00 Code B1

The projected payment amount is then $550.

CLP*1234567890*25*1100*0*250**9012345678~
SVC*HC:99255*1100*0**3**4~
RAS*50*PR*1~
RAS*200*PR*2~
RAS*200*CO*45~
RAS*100*CO*B1*1~
RAS*550*OA*101~

1.10.2.8 Reversals and Corrections

When the claim adjudication results have been modified from previous reporting, the method for revision is to first reverse the entire claim and then resend modified data, and must appear in that order if in the same transaction. 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.2 - Reported Amounts:

Table 1.2 - Reported Amounts

Submitted charges $100.00
Allowed Amount $80.00

Adjustments

  Disallowed amount

  Coinsurance

 

$20.00

$16.00

Deductible $24.00
Payment amount $40.00

Original Payment

CLP*1234567890*1*100*40*40**12345*********612~
RAS*24*PR*1~
RAS*16*PR*2~
RAS*20*CO*45~
AMT*B6*80~

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, including using the appropriate Reversal and Correction Alert Remark Code in the 2100 loop LQ segment to indicate the reason for the reversal and correction (pharmacy will use the 2110 loop LQ). This restores 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. If the reversal and correction appear in the same transaction, the reversal must appear in the transaction first, then the correction.

NCPDP specifications providing specific use within the retail pharmacy industry for pharmacy transactions are available at: http://www.ncpdp.org.

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

Reversing the original claim payment of a primary claim is accomplished with Claim Status Code 32, (Reversal of Previous Payment for Primary Claim) in CLP02. Reversing the original claim payment for a secondary claim is accomplished using code 33 (Reversal of Previous Payment for Secondary Claim), and tertiary (or subsequent) claim using code 34 (Reversal of Previous Payment for Tertiary Claim). Send original Claim Adjustment group codes in RAS02, CARCs and RARCs in RAS03, and appropriate adjustments. All original charge, payment, adjustment, and other informational amounts are negated.

For the current example, the reversal and corrected claim payment would appear as:

CLP*1234567890*32*-100*-40*-40**12345*********612~
RAS*-24*PR*1~
RAS*-16*PR*2~
RAS*-20*CO*45~
LQ*HE*N692~
AMT*B6*-80~

CLP*1234567890*1*100*24*36**67890*********612~
RAS*24*PR*1~
RAS*12*PR*2~
RAS*40*CO*45~
AMT*B6*60~
REF*F8*12345~

NOTE

  • Caution, while the claim paid amount (CLP04) for this claim payment can be zero or less, the reversal method included in this section (Section 1.10.2.8 - Reversals and Corrections), may cause the total payment for this 835 (BPR02) to become negative. If the corrected claim payment would result in an 835 with a negative balance (BPR02), the balance forwarding process identified in Section 1.10.2.12 - Balance Forward / Forward Recovery Processing is used to eliminate the negative value in BPR02.
  • 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. When the CLP07 value for the corrected claim is different than the CLP07 value from the original claim, one iteration of the Loop ID 2100 REF - ORIGINAL PAYER CLAIM CONTROL NUMBER segment with REF01 equal to F8 (Original Reference Number) and REF02 equal to the original CLP07 value is required in the correction claim.
  • See section 1.10.2.9 for the Reversal and Correction process related to Interest and Prompt Pay Discounts.

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 (Note-these descriptions are as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.):

  • L6 - Interest amount

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

  • 90 - Early payment allowance amount

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 amount," and 90, "early payment allowance amount" (Note-these descriptions are as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.)
  • If any interest responsibility and/or prompt pay discounts are extended to the patient, report the data in the RAS 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, 2011.
  • 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, 2012. 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~
RAS*1000*PR*1~
NM1*QC*1*Jones*Melvin~
AMT*I*67.81~
PLB*12345*20120124*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. Details about the membership roster are sent external to the 835. 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 where an identifying reference number for the list is included, that list identifier is provided as a PLB provider adjustment identifier 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 (Note-these descriptions are as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description):

  • AM - Loan repayment amount
  • CR - Capitation interest amount
  • CT - Capitation payment amount
  • E3 - Withholding amount
  • FC - Allocation of prepaid funds against which deductions are drawn as services are provided.
  • IP - Incentive payment amount
  • L3 - Penalty amount
  • RA - Retroactive adjustment amount
  • TL - Third party liability determination amount

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 Provider's Assigned Claim Identifier (CLM01) must be returned on all split claims in CLP01. The provider's original submitted Line Item Control Number (Loop 2400 REF) 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 Service Line 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 2100 loop LQ Segment with Remittance Advice Remark Code MA15 (Alert: Your claim has been separated to expedite handling. You will receive a separate notice for the other services reported.) (Note - this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.) on each of the adjudicated (split) claims. See the 2100 Loop LQ segment detail for specific usage instructions.

For information on service line splitting, see Section 1.10.2.14.2 - Service Line Splitting.

1.10.2.12 Balance Forward / Forward Recovery 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 should be clarified. Since the 835 is a financial transaction and not just a report, the payment amount cannot 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 / Forward Recovery Processing.

1.10.2.12.1 Balance Forward Not Related to a Specific Claim

This process is typically used by pharmacy payers to report Forward Balance amounts using the FB Provider Adjustment Reason Code rather than the individual claim amounts. Other non-pharmacy situations are processed using the "Forward Recovery Related to a Specific Claim" process.

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 balance forward occurs only at the transaction level not at the claim level.

The business objectives are:

  • The payment amount of the current 835 cannot be less than zero.
  • In some situations, due to contractual or other requirements, the payment amount cannot be zero.
  • The previous negative balance will be added into a future 835 transaction.
  • The 835 must identify to the provider what has happened.
  • A reference number must be included 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-01 will be FB, "Non-claim related balance forward amount" (Note-this description is as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.) The reference number in PLB03-02 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.

In situations where, due to contractual or other requirements, the payment amount cannot be zero, the dollar amount in PLB04 will be more than the current negative balance, to allow for a positive payment to the payee.

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

PLB*1234567890*20181231*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 (recouping the amount):

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-01 contains FB, "Non-claim related balance forward amount" (Note-this description is as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.) PLB03-02 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 transaction, but as a positive value. The positive number reduces the payment in this 835.

Continuing the same example as above, the PLB segment for the future remittance advice for the provider will be:

PLB*1234567890*20181231*FB:1234554*200~

Ongoing forwarded balances:

In situations where the full forwarded balance is not satisfied in the current 835, for non-claim specific balance forwards, the balance forward amount will appear in a PLB in each 835 until the entire balance forward is satisfied. Each subsequent 835 will include a PLB with Provider Adjustment Code FB, and Reference Identifier (PLB03-02) will contain the same trace number (TRN02) as has appeared in the previous 835, and will have a positive adjustment amount for the balance forward amount. In addition, if the entire balance forward is not satisfied, an additional adjustment must be included, also with Provider Adjustment Code FB. This adjustment will include the current trace number (TRN02) in the Reference Identifier (PLB03-02), and will have a negative amount to carry the balance forward (to ensure the transaction balances).

Continuing the same example as above, the PLB segment for the future remittance advice for the provider will be:

PLB*1234567890*20181231*FB:1234554*200*FB:6789000*-150~

Indicating that $50 of the $200 Balance Forward is being recouped, and $150 is continuing forward as a Balance Forward.

1.10.2.12.2 Forward Recovery Related to a Specific Claim

The PLB segment's ability to report adjustments related to specific claim(s) also allows for a forward recovery adjustment. This capability allows a payer to move the negative balance (outstanding recoupments) from the current 835 transaction into a future transaction on a per claim basis.

The business objectives are:

  • The payment amount of the current 835 cannot be less than zero.
  • In some situations, due to contractual or other requirements, the payment amount cannot be zero.
  • The previous negative balance related to the claim(s) will be added into a future 835 transaction.
  • The 835 must identify to the provider what has happened.
  • A reference number must be included for reconciliation of the forward recovery 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 Forward Recovery adjustment in the PLB segment. (While any adjustment pair can be used in the PLB, PLB03 and PLB04 will be used for illustrative purposes.)

PLB03 is reported as follows:

PLB03-01 Adjustment Reason Code, the appropriate FR (Claim-related balance forward amount) adjustment reason code (Note-this description is as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.)

PLB03-02 Reference ID, report the Unique Individual Claim Number:

  • Characters 1-35 are CLP01 (Provider's Assigned Claim Identifier), space filled when necessary, (limited to 35 due to limits assigned in the 837 CLM01)
  • Character 36 is space,
  • Characters 37-80 are the first 44 characters of CLP07 (Payer Claim Control Number),

This reference number will facilitate tracking by the provider.

PLB04 includes the amount that the individual claim contributed to the negative balance to be recovered in a subsequent 835.

There will a PLB adjustment pair only for each claim that contributed to that 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 (BPR02) may be $0.00, but cannot be negative. The value in BPR02 will be 0.

In situations where, due to contractual or other requirements, the payment amount cannot be zero, the dollar amount in PLB04 will be more than the current negative balance, to allow for a positive payment to the payee.

Assume that the current net payment for the transaction for provider NPI "1234567890" is $-200.00 and that the CLP01 Provider's Assigned Claim Identifier is "0987653210" and the CLP07 Payer Claim Control Number is "ABCDEFGHI". Specifications outlined above for the Reference ID state that the first 35 characters include CLP01 and then are space-filled; however, for illustrative purposes only, only the first 10 characters are included, with no space fill.

To move the recovery forward, the PLB segment will read:

PLB*1234567890*20181231*FR:0987653210 ABCDEFGHI*-200~

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

Adding the previously forwarded recovery to a new 835 (recouping the amount):

When a forward recovery adjustment was reported in a previous 835, a future 835 must report either all or a portion of the money to be recovered in order to complete the process of recouping the overpayment amount. In this case, the PLB segment is again used as the mechanism. PLB03-01 contains WO, "Overpayment Recovery Amount ".

PLB03-02 contains the same reference number from the PLB segment of the previous 835. This allows the receiver to quickly reconcile the two forward recovery adjustments. PLB04 contains the same dollar amount as the previous transaction, but as a positive value. The positive number reduces the payment in this 835.

Continuing the same example as above, the PLB segment for the future remittance advice will be:

PLB*1234567890*20181231*WO:0987653210 ABCDEFGHI*200~

The forward recovery amount only appears in an 835 where a recoupment is taking place for that claim. The ongoing forward recovery balance does not appear in each 835. If some or all of the forward recovery is being taken in this 835, then the sign of the dollar amount in the PLB is positive to reduce the amount in BPR02. See Section 1.10.2.1.3 - Transaction Balancing for additional information.

Because the claim was already adjusted in the Reversal & Correction process, forward recovery reporting occurs only at the PLB transaction level. No claim or service level information is adjusted as part of the forward recovery process.

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

Ongoing forward recoveries:

In situations where the full forwarded recovery for that claim is not satisfied in the current 835, the recovery is carried forward. This information will not appear in a subsequent 835 until activity occurs on the forward recovery for that specific claim.

When activity occurs on the forward recovery for that claim, then a PLB adjustment with Provider Adjustment Code WO will appear in the 835, and will include the claim-specific Reference Identifier in the PLB03-02. The amount included in PLB04 is the amount being recouped for this claim, with a positive sign. The claim-specific Reference Identifier in PLB03-02 must be the same throughout the entire process to ensure the provider can track the Forward Recovery amount and recoupments for that claim.

Note: The claim-specific adjustments will only appear in an 835 when activity occurs on the forward recovery (e.g. amount being recouped). The ongoing rolling forward recovery balance is not included in an 835 unless an amount is being recouped from the balance.

Using the initial example from above, when a recoupment occurs from the forward recovery balance, the PLB segment for the remittance advice will be:

Current forward recovery balance: $200

PLB*1234567890*20181231*FR:0987653210 ABCDEFGHI*-200~

Week 1 835: amount being recouped is $50. The PLB is reported as:

PLB*1234567890*20181231*WO:0987653210 ABCDEFGHI*50~

Week 2 835: amount being recouped is $25. The PLB is reported as:

PLB*1234567890*20181231*WO:0987653210 ABCDEFGHI*25~

Week 3 835: amount being recouped is $125. The PLB is reported as:

PLB*1234567890*20181231*WO:0987653210 ABCDEFGHI*125~

Forward Recovery amounts that are claim-specific versus non-claim specific (Balance Forward) are mutually exclusive and should never be intermingled. Forward Balances that initially began as non-claim specific should continue as such until fully satisfied. Conversely, forward recoveries that ARE specific to a claim must be reported as claim-specific forward recoveries until the entire amount is recouped.

1.10.2.13 Subsequent (Secondary / Tertiary) Payment Reporting Considerations

Sometimes 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. As a result of Coordination of Benefits (COB), it is likely a provider will receive multiple claim payments related to a single patient accounting record or event.

  • Secondary and tertiary payers are frequently referred to as "subsequent" payers.
  • All previous payer(s) are frequently referred to as the prior payer(s).
  • All plans beyond the primary and secondary payers are considered tertiary.

The 835 allows the receiver to automatically post the remittance detail at either the claim or service line level. The governing principles are based upon the receiver's needs and the enabling of automation.

Each claim reported within an 835 transaction must account for 100% percent of the original submitted charge for the related services. Every claim reports the same original submitted charge, not just the unpaid balance.

The results reported by subsequent payers must include information from the prior payers in order to balance. Care must be taken by the payer to ensure that amounts are not sent in a way that providers will apply the same adjustment multiple times to their Accounts Receivable (AR), which would negatively impact the provider's AR system (i.e., cause negative balances). To automate posting for the provider, those prior posted items must be identifiable to the AR system so that they can be handled appropriately as informational and not be posted to the AR.

Report the prior payers' total payment and provider contractual adjustment in the appropriate claim or service level RAS segment. Use OA (Other Adjustment) in the Claim Adjustment Group Code and "23" in the CARC (Claim Adjustment Reason Code). CARC 23 currently has a description that reads "The impact of prior payer(s) adjudication including payments and/or adjustments. (Use only with Group Code OA)". (Note-this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.)

The term "impact" in that description is to be used to identify the payments and provider contractual reductions that have already been posted to the AR by the provider. This even applies when the secondary payer doesn't take into account what a prior payer actually adjudicated.

Common principles that apply when reporting as a secondary or tertiary payer:

  • Report whether the claim is being processed as secondary or tertiary in the claim status code (CLP02).
  • Report the allowed amount in the AMT segment at either the claim or service level (as appropriate) using qualifier B6 (Allowed-Actual) in AMT01. The allowed amount represents the amounts that apply under the benefit provisions of the health plan used for adjudication. See TR3 Notes for the 2100 and 2110 AMT segments for additional information.
  • Report any prior payer(s) payment and provider contractual adjustment amounts in a 2100 or 2110 RAS segment using Claim Adjustment Group Code OA and CARC 23.
    • Do not include any amount adjusted by the prior payer with a group code indicating Payer Initiated (e.g. PI) or a group code indicating Patient Responsibility (e.g. PR) in the calculation of the OA 23 adjustment.
  • Report any additional adjustment amounts not previously reported as OA 23 in a 2100 or 2110 RAS segment using the appropriate Claim Adjustment Group Codes, Claim Adjustment Reason Codes (CARC), and Remark Codes (RARC and IISRC).
  • Report any amounts over the billed charges using CARC 94 and a negative adjustment amount.

The above steps do not apply to the first payer to adjudicate the claim.

For more information on where the subsequent payer can obtain the prior payer's COB adjustment information when submitted electronically, please refer to section 1.4.2 in the 837 TR3s. For Pharmacy claims, please refer to the NCPDP Telecommunications Standard.

The following scenarios identify how this process is applied to differing situations, but may not represent all possible scenarios. They apply equally to claim level or service level requirements.

Scenario #1 – Secondary payer allows the same as the primary payer, but less than the original submitted charge, and pays the entire remaining balance.

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02) $250   $250  
Allowed Amount (AMT*B6) $180   $180  
Patient Responsibility $80 Deductible RAS*80*PR*1~    
Payment (CLP04 or SVC03) $100   $80  
COB Adjustment       RAS*170*OA*23~ (100 pmt + 70 contractual adj)
Other Adjustment   RAS*70*CO*45~    


Scenario #2 – Secondary payer allows less than the primary payer, and pays based upon their own lower allowed amount.

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02)$250 $250 
Allowed Amount (AMT*B6)$180 $150 
Patient Responsibility$80 DeductibleRAS*80*PR*1~  
Payment (CLP04 or SVC03)$100 $50 
COB Adjustment   RAS*170*OA*23~ (100 pmt + 70 contractual adj)
Other Adjustment RAS*70*CO*45~ RAS*30*CO*45~


Scenario #3 – Secondary payer allows the same as the primary payer, which was more than the original submitted charge, and pays based on the same allowed amount.

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02)$500 $500 
Allowed Amount (AMT*B6)$700 $700 
Patient Responsibility$100 DeductibleRAS*100*PR*1~  
Payment (CLP04 or SVC03)$600 $100 
COB Adjustment   RAS*600*OA*23~ (600 payment)
Other Adjustment RAS*-200*OA*94~ RAS*-200*OA*94~


Scenario #4 – Primary payer allows more than the original submitted charge. Secondary payer allows only the original submitted charge, and pays patient responsibility up to what they would have paid if they were primary. In this example, the primary payer payment and adjustment amounts, plus the secondary payment amount, is greater than the original submitted charge. The secondary remit is then balanced using an OA 94 adjustment because the secondary payer processed the amount (including the impact of the primary payer) in excess of charges.

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02)$500 $500 
Allowed Amount (AMT*B6)$700 $500 
Patient Responsibility$100 DeductibleRAS*100*PR*1~  
Payment (CLP04 or SVC03)$600 $100 
COB Adjustment   RAS*600*OA*23~ (600 payment)
Other Adjustment RAS*-200*OA*94~ RAS*-200*OA*94~


Scenario #5 – The primary payer allows services that the secondary payer does not. The secondary payer denies the claim because the service is not covered under the benefit plan; therefore, the secondary payer's allowed amount is zero. (CARC 204 is used as an example only for the reason the service is not covered. This same process will occur for other situations like duplicate claims, member not covered, etc.).

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02)$500 $500 
Allowed Amount (AMT*B6)$400 $0 
Patient Responsibility$100 DeductibleRAS*100*PR*1~ RAS*100*PR*204~
Payment (CLP04 or SVC03)$300 $0 
COB Adjustment   RAS*400*OA*23~ (300 pmt + 100 contractual adj)
Other Adjustment RAS*100*CO*45~  


Scenario #6 – Primary payer applied entire allowed amount to patient responsibility. The secondary payer's allowed amount is greater than the primary payer's allowed amount. The secondary payer does cover the charges, and pays based on their allowed amount. In this example, the primary payer payment and adjustment amounts, plus the secondary payment amount, is greater than the original submitted charge. The secondary remit is then balanced using an OA 94 adjustment because the secondary payer processed the amount (including the impact of the primary payer) in excess of charges.

  Primary Primary Adjustment Secondary Secondary Adjustment
Submitted Charge (CLP03 or SVC02) $500   $500  
Allowed Amount (AMT*B6) $300   $350  
Patient Responsibility $300 Deductible RAS*300*PR*1~ $70 Coinsurance RAS*70*PR*2~
Payment (CLP04 or SVC03) $0   $280  
COB Adjustment       RAS*200*OA*23~ (200 contractual adj)
Other Adjustment   RAS*200*CO*45~   RAS*-50*OA*94~

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 usage of the information in the 835 depends upon the context of a particular service. Since the Claim Adjustment Reason Codes used in the RAS 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 RAS 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 RAS 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 Reporting Invalid or Unrecognized Procedure Information (SVC01 / SVC06) in the 835

There are situations where invalid or unrecognized procedure information (procedure code and/or modifier) is submitted on the claim. Examples are paper claims, payers who are unable to reject electronic claims at the front end, and regulatory situations where procedure codes are mandated that are not part of the code list. In these situations, the preferred process would be to reject claims prior to adjudication when there is invalid procedure information. The expectation is that the submitter would correct the data and resubmit the claim.

In situations where payers may not be able to accommodate the practice of rejecting prior to adjudication (or where the code is required by regulation), the claim is allowed into the system. Some payers may be able to determine the correct procedure information for processing and can continue with adjudication. When this occurs, the valid procedure information used for adjudication is reported in SVC01. The adjudicated procedure information is from one of the external code sources defined by qualifiers in SVC01-01. The originally submitted procedure information is reported in SVC06 and since the code or modifier that was submitted was identified as an invalid or unrecognized code or modifier, the 'RA' qualifier is used in SVC06-01. Since SVC06 would contain an invalid or unrecognized code or modifier, it would not be validated against any external code list.

In instances where the correct procedure information cannot be determined and adjudication continues with the invalid or unrecognized procedure information, the processing may result in a denial due to the procedure information. The invalid or unrecognized procedure information used for adjudication appears in SVC01 using the 'RA' qualifier in SVC01-01. Since SVC01 would contain an invalid or unrecognized code or modifier, it would not be validated against any external code list.

For Procedure / Revenue Code combinations:
If the claim was adjudicated based upon the procedure code (even if the revenue code was invalid), then the procedure code is reported in SVC01 and revenue code is not reported in SVC04.

If claim was denied due to an invalid revenue code, then the revenue code is reported in SVC01 with the RA qualifier, and the procedure code is not reported because it was not considered.

If both are invalid, either (whichever is most important to the adjudication process) can be reported in SVC01 with the RA qualifier, and remark codes are reported indicating that both are invalid.

1.10.2.14.2 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 needs to be split by the payer for business reasons. Business issues represent situations where specific service unit adjudication varies to the point the service must be split in order to accurately report adjudication results in the 835.

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 with multiple units 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 number as the line item control number.
  • Report one LQ segment iteration for each split service line with LQ01 equal to HE and LQ02 equal to N123, "Alert: This is a split service and represents a portion of the units from the originally submitted service." (Note - this description is as of the publication of this book. Please refer to www.wpc-edi.com for the most current description.).

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 Code DOS Submitted Chgs. Units Paid Amount
01 A 01/01/12-03/01/12 400.00 4 360.00


As processed by Payer

LnCtrl# Procedure Code DOS Submitted Chgs. Units Paid Amount
01 A 01/01/12-01/31/12 100.00 1 100.00
01 B 02/01/12-03/01/12 300.00 3 260.00


835 Example:

SVC*HC:A*100*100**1~
REF*6R*01~
LQ*HE*N123~
SVC*HC:B*300*260**3*A~
RAS*40*CO*45~
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 Code DOS Submitted Chgs. Units Paid Amount
01A12/1/12-1/30/12800.008 


As processed by Payer

LnCtrl# Procedure Code DOS Submitted Chgs. Units Paid Amount
01A12/1/11-12/31/11400.004400.00
01A1/1/12-1/30/12400.004360.00


835 Example:

SVC*HC:A*400*400**4~
REF*6R*01~
LQ*HE*N123~
SVC*HC:A*400*360**4~
RAS*40*PR*2~
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

REV Line DOS Submitted charge Per unit charge Units Paid
1A 300.00150.2 
2B 400.00100.4 
3C 250.00505 
4D 60.0010.6 
5E9/28-10/0380.0020.4 
  1090.00  1090.00


Split Claim: Claim 1

REV Line DOS Submitted charge Per unit charge Units Paid
1A 300.00150.2300.00
2B 400.00100.4400.00
5E9/28-9/3040.0020.00240.00
      

835 for Claim 1

CLP*12345*1*740*740***123456789~
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*20120928~
DTM*151*20120930~
REF*6R*5~
LQ*HE*N123~

Split Claim: Claim 2

REV Line DOS Submitted charge Per unit charge Units Paid
3C 250.00505250.00
4D 60.0010.660.00
5E10/01-10/0340.0020.240.00
      

835 for Claim 2

CLP*12345*1*350*350***123456798~
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*20121001~
DTM*151*20121003~
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 include but are 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 RAS segment contained in loop 2100 or 2110. The adjustment amount is reported in RAS01, the "Contractual Obligation" group code in RAS02 and the adjustment reason code in RAS03. To report the PPO, use the Class of Contract REF segment. The qualifier CE (Class of Contract Code) is reported in REF01 and the name or identifier of the PPO is reported in REF02. 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 re-priced by PPO A to $55.00. The pertinent segments of the claim would appear as follows:

RAS*20*CO*45~
REF*CE*PPO A~

When the payer uses an agent (e.g. Third Party Administrator) to issue payments, and that agent's information appears in Loop 1000A, then the payer's information is reported in REF04-02.

For example, assume that Payer A with Payer ID 12345 has contracted with TPA One to issue payments. The pertinent segments of the transaction would appear as follows:

N1*PR*TPA One~
REF*CE*PPO A**2U^12345~

For pharmacy transactions, the Class of Contract Code information may also be provided in the NCPDP claim response, when relevant. See the guidance provided in NCPDP Pharmacy Reference Guide to the X12/007030X322 Health Care Claim Payment/Advice (835), available from NCPDP under Resources/Guidance Documents at:

http://www.ncpdp.org.

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 payers strive for accurate adjudication on the first pass, occasionally adjudication errors are detected 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 outlines the necessary actions within the 835. However, when the re-adjudication of the claim results in a reduction of the claim payment amount, the business gets more complicated in how to accomplish the recovery of the overpayment. Claim overpayment recovery should still utilize the reversal and correction process outlined in Section 1.10.2.8, but may include additional steps to notify the provider. The payer should specify its notification methodology for claim overpayment recovery in either a trading partner agreement or a provider contract.

When a payer recoups the overpayment within the remittance advice (835) using the reversal and correction process, the funds are taken at that time. The reversal and correction instructions in Section 1.10.2.8 - Reversals and Corrections describe the necessary actions. These reversal and correction claims should not be reported in a separate zero-pay 835 transaction set, but should be included with the other claims in the 835.

Whenever there is no state law, other regulation, or contractual agreement preventing immediate recoupment, the current 835 must resolve any recoupment and should occur immediately via the reversal and correction process. Claim amounts that are not fully recouped should be reported individually in the PLB - Provider Adjustment segment (and in subsequent 835 PLBs) to provide detail to the provider on the ongoing forward recoveries for each corrected claim. See Section 1.10.2.12.2 - Forward Recovery Related to a Specific Claim for additional information.

Pharmacy payers typically send a single Forward Balance amount using the FB Provider Adjustment Reason Code rather than the individual claim amounts. Refer to Section 1.10.2.12.1 - Balance Forward Not Related to a Specific Claim for additional information. If pharmacy payers are reporting individual claim recovery, then follow the Overpayment Recovery instructions.

  1. Report the reversal and corrected claims in Loop ID 2100 (Claim Payment Information), identified with the appropriate CLP02 (Claim Status Code).
    • Must use the reversal ALERT RARCs (Use RARCs that contain the wording "This reversal is due to...") in the 2100 or 2110 LQ segment of the reversal claim in addition to any RARCs that were present in the original claim that is being reversed.
      Note - if there are no RARCs that explain the reason for the reversal, see Section 1.10.2.4.4 - Remark Codes for instructions on requesting a new code.
    • If the 835 payment amount (BPR02) is sufficient to cover the amount(s) recouped in the reversal and correction process, then no further action is needed.
  2. If the 835 payment amount (BPR02) is less than the total needed to allow recoupment of all corrected claims, then see Section 1.10.2.12 - Balance Forward / Forward Recovery Processing for reporting the Forward Recovery information in the PLB segment.

Notifications (paper or electronic) may be needed for the provider depending on payer practices, contractual agreements, or regulatory requirements. The notification should include CLP01 (Provider's Assigned Claim Identifier) and CLP07 (Payer Claim Control Number) from the 835. In some cases, the reversal and correction within the 835 can also act as the notification. When regulations or contracts require delay in recouping overpayments, the notification acts as the initial notice that starts the related time frame.

The corresponding 835 should include the reversal and correction for the claim involved. To prevent the funds from being recouped immediately (when delays are required), include a PLB adjustment with Provider Adjustment Code WO and negative adjustment amount to reflect that the funds will be recouped at a future time. The appropriate reversal and correction RARCs should also be included as described above.

Providers are advised to refrain from sending payments directly to payer's plans to settle overpayment notifications or to unilaterally return funds believed to be received in error, unless explicitly requested to do so by the payer. If the provider chooses to remit the balance due with a check, the provider should reference the CLP01 and CLP07 from the claim that the check relates to on the check itself. The health plan must 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. Provider Adjustment Codes 72 (Provider refund amount) and WO (Overpayment recovery amount) are used. (Note-these descriptions are as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.) Use the Reference Identification number from the original overpayment notification (WO) including both CLP01 and CLP07 as outlined in 1.10.2.12. Note – if no claim information is noted on the provider's check, the health plan must have a process to identify what claim the check is related to.

Example: A health plan sends a notification to a provider (number 1234) identifying an overpayment of $37.50. On the original notification of overpayment, the CLP01 Provider's Assigned Claim Identifier is "0987653210" and the CLP07 Payer Claim Control Number is "ABCDEFGHI". Specifications outlined in 1.10.2.12 for the Reference ID state that the first 35 characters include CLP01 and then are space-filled; however, for illustrative purposes only, only the first 10 characters are included, with no space fill. Before the specified deadline, the provider remits the overpayment to the health plan, identifying the Reference ID with the payment. A PLB segment in the next 835 would report this payment.

PLB*1234*20181231*WO:0987653210 ABCDEFGHI*37.5*72:0987653210 ABCDEFGHI*-37.5~

Note: Property & Casualty, while currently using a manual process for this situation, is neither prohibited from using the automated functions of the 835 for overpayment recovery, nor required to do so.

EXAMPLES

Initial 835 Original:

CLP*12345*1*1000*500*300**987654321*11*1*******51~
RAS*200*CO*45~
RAS*300*PR*1~

Second 835 Reversal and Correction
Full Recoupment - No Balance Moving Forward

BPR*I*590*C*ACH*CCP*01*123465789*DA*123458*0123456789**01*12345*DA*123456*20180101~
CLP*12345*32*-1000*-500*-300**987654321*11*1*******51~
RAS*-200*CO*45~
RAS*-300*PR*1~
LQ*HE*N692~
CLP*12345*1*1000*340*300**987654321*11*1*******51~
RAS*360*CO*45~
RAS*300*PR*1~
CLP*543210*1*3000*750*500**123654321*11*1*******61~
RAS*1750*CO*45~
RAS*500*PR*1~

The total of all of the non-reversal claim payments in this 835 is $1090. The reversal claim reduces that amount by $500. Because the resulting payment amount of $590 is still positive, no Forward Recovery is required. (The sum of all CLP04 amounts is positive, so no Forward Recovery is required.)

Second 835 Reversal and Correction
Partial Recoupment - with Forward Recovery (check amount does not cover the recoupment amount or other regulations or contracts limit the amount that can be recouped):

Initial 835 Original:

CLP*12345*1*1000*500*300**987654321*11*1*******51~
RAS*200*CO*45~
RAS*300*PR*1~

Second 835 Reversal and Correction

BPR*H*0*C*NON************20180101~
CLP*7890123456*32*-1000*-500*-300**987654321*11*1*******51~
RAS*-200*CO*45~
RAS*-300*PR*1~
LQ*HE*N692~
CLP*7890123456*1*1000*340*300**987654321*11*1~
RAS*360*CO*45~
RAS*300*PR*1~
CLP*543210*1*300*100*200**123654321*11*1*******61~
RAS*200*PR*1~
PLB*12345*20140128*FR>7890123456 987654321*-60~

The total of all of the non-reversal claim payments in this 835 is $440. The reversal claim reduces that amount by $500. Because the resulting payment amount would be negative, the payment is reduced to $0 and a Forward Recovery amount of $60 is required. (The sum of all CLP04 amounts is negative, so Forward Recovery is required.)

Specifications outlined in 1.10.2.12 for the Reference ID state that the first 35 characters include CLP01 and then are space-filled; however, for illustrative purposes only, only the first 10 characters are included, with no space fill.)

In the next 835, the Forward Recovery amount of $60 is recouped

BPR*240
CLP*300
PLB*12345*20180128*WO>7890123456 987654321*60~

The total of all of the non-reversal claim payments in this 835 is $300. The recoupment of the Forward Recovery amount reduces the payment by $60, resulting in a net payment of $240.

Specifications outlined in 1.10.2.12 for the Reference ID state that the first 35 characters include CLP01 and then are space-filled; however, for illustrative purposes only, only the first 10 characters are included, with no space fill.)

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.

A standardized list of Claim Adjustment Reason Codes and Claim Adjustment Group Codes are used in the RAS - Claim Adjustment Information and RAS - Service Adjustment Information segments. See Appendix A, External Code Sources, for the List locations, and refer to these lists for the most current valid codes and descriptions.

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 RAS01 values in the appropriate 2100 / 2110 loop where RAS03-01 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 RAS01 values in the appropriate 2100 / 2110 loop where the group code in RAS02 indicates "Contractual Obligations".

Total Coinsurance Amount - sum of the RAS01 values in the appropriate 2100 / 2110 loop where the value in RAS03-01 has a description that reflects "Coinsurance".

Total Deductible Amount - sum of the RAS01 values in the appropriate 2100 / 2110 loop where the value in RAS03-01 has a description that reflects "Deductible".

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 the claim and/or service is an encounter. The payer identifies this through adjudication. Submitters may indicate an 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 the payer determines are covered under the capitation agreement must be adjusted to $0.00 payment using CARC 24 (Charges covered under a capitation agreement/managed care plan). (Note-this description is as of the publication of this book. Please refer to www.wpc-edi.com <http://www.wpc-edi.com> for the most current description.)

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 Information and Service Adjustment Information Segment Theory (Institutional-Specific Use).

1.10.2.20 Retroactive Claim Adjustments

Situations occur when a payer processes large number of adjustments retroactively that are sent periodically based on various reimbursement or recoupment situations.

Retroactive adjustments are identified by the Remark Codes that include a reference to "retroactive adjustments" which are included in the claim level LQ segment of the reversal during the reversal and correction process. Pharmacy is the exception. Retroactive adjustments for pharmacy are processed at the service level and may include Claim Adjustment Reason Codes using the reversal and correction process.

The payer's retroactive adjustments are included in the normal payment cycle and not in a separate 835 because the retroactive adjustment could be a recoupment of an overpayment.

This allows providers, depending on the retroactive situation, the alternative to update their Accounts Receivable or split off the patients who have retroactive adjustments and create a journal entry with the retroactive adjustment amount.

1.10.2.21 835 Message Matching

The message of the 835 for a given service line or claim must be consistent with the business message provided by the payer through any alternate delivery method to the provider including Internet portals, paper remittance advices, facsimile, and telephone support services, etc.

This does not require or even suggest that the health plans or their agents must support an alternate delivery method, but if one exists, then the messages must not contradict each other.

All adjustments at the service, claim, and transaction levels must be valid adjustments that pertain to the adjudication of the claims.

The payer is responsible for accurately mapping its internal codes for denials and adjustments to the standard code sets so all related parts of the 835 convey a complete message. Should a health plan determine they have a message they cannot convey with the existing codes, the health plan is responsible for requesting a new or modified code from the code set owners (see Section 1.10.2.4 - Claim Adjustment Information and Service Adjustment Information Segment Theory) and/or seeking advice from X12 via a Request for Interpretation submitted at www.x12.org.

1.10.2.22 Billing Provider as Payee

Due to the current limitation of some payers, vendors and clearinghouses, the routing of the 835 does not meet the needs of providers nor match the way the claims are submitted using the billing provider number (National Provider Identifier (NPI)). Some providers have established subpart NPIs for the purpose of separating the 835s so that they can be processed in different billing systems. Claim payments should not be grouped by TAX ID if the claim was billed with an NPI, unless a mutual agreement exists between the provider and payer.

835s should be generated based on the payee identified in Loop 1000B:N104 which must correspond to the value received on the claim as the billing provider number (NPI) (for example: loop 2010AA in an 837). An exception is allowed when there is a mutual agreement between the payer and billing provider.

In the case where the payee is an atypical provider, the Federal Tax Identifier used in the claim must be used to generate (and route) the 835 claim payments. An exception is allowed when there is a mutual agreement between the payer and billing provider.

While the 835 must be routed based on the value received on the claim, it's understood that the recipient of the 835 may not be either the payee or billing provider (billing service or clearinghouse) but must be approved by both to receive the 835 information.

Since the pharmacy industry conducts virtually all of their claims in a real time processing environment using the NCPDP Telecommunication Standard as defined by HIPAA, the use of the 835 for pharmacy payments and pharmacy 835 routing information does not follow the same methodology. Therefore, this rule exempts the pharmacy industry. Those that use the 835 for reporting pharmacy transactions should refer to the NCPDP website at: https://www.ncpdp.org

1.10.2.23 Basis of Adjudication

Claim adjudication can be impacted by factors that are controlled by a regulation or the terms of a provider's contract with the health plan. To understand and validate the payment, the provider must know which of these factors were actually applied when the health plan adjudicated a particular claim.

Pertinent factors can include (but are not limited to):

  • health insurance product
  • provider network
  • provider contract
  • other contracting party, if not the health plan
  • reimbursement methodology
  • applicable fee schedule or rate structure

The intended instruction is to standardize how this information is identified in the transaction.

The health plan must determine the pertinent factors that apply to its business and then codify or create short standard text statements to identify them. Health plans must use the same codes or standard text for all payees and not customize them by provider. The health plan must communicate the code or standard text meanings to providers on a regular, timely basis. Communication can be done via website, email, mail, etc.

To indicate under which regulatory requirement(s) or contract term(s) the claim was adjudicated, the health plan must use the segment "REF – Class of Contract Code" in loop 2100 of the 835. REF01 is valued with qualifier code "CE", Class of Contract Code. REF02 is valued with the health plan's applicable code(s) or standard text statement(s).

For pharmacy transactions, the Class of Contract Code information may also be provided in the NCPDP claim response, when relevant. See the guidance provided in NCPDP Pharmacy Reference Guide to the X12/007030X322 Health Care Claim Payment/Advice (835), available from NCPDP under Resources/Guidance Documents at:

1.10.2.24 Data Integrity

The accuracy and detailed contents of the remittance information is critical to being usable for posting. Inaccurate or incomplete remittance information defeats the advantages of an electronic remittance advice and adds cost to the health care system, necessitating manual posting, access to payer portals, or phone calls to complete the task. Compliance with the structure and code sets of the 835 without remittance information integrity is not compliant with this guide.

835 data integrity must be maintained, as submitted by the payer, by any and all third parties. The term third party includes Value-Added Networks (VANs), Clearinghouses, and Billing Services, as well as Hospital Information System (HIS) and Practice Management System (PMS) vendors. For example: while allowed amounts in the AMT segment are not part of the financial balancing of the 835, the detail of all the information that applies to specific claims and service lines is very important and must be supplied. Without explicit approval from their trading partners, all information must be forwarded through third parties to the providers without alteration, recalculation or truncation.

If a provider requests an 835, all data element requirements and situational rules must be accommodated, regardless of the source of the claim (paper or electronic). The 835 handles paper and electronic claims equally and the requirements for both are the same.

When data is received on the claim that impacts the processing of the claim, Claim Adjustment Reason Codes and Remark Codes are returned in the 835 to communicate to the sender of the claim the reasons why and how the claim was adjusted by the health plan. In the case of missing claim data where the claim (e.g., paper) is not rejected up front, use of appropriate and compliant default data may be used (e.g., zip code).

When a paper claim is submitted with missing or invalid procedure and/or revenue codes and is not rejected upon receipt, the outbound 835 will be non-compliant even if the service line with the bad code is denied. If the payer is able to replace the invalid code with a valid one during adjudication, the health plan provides the code used in adjudication with the appropriate qualifier in SVC01 and the originally submitted code with the qualifier "RA-Return Code" in SVC06. If the payer denies the service due to the invalid code, then the invalid code must be returned in SVC01 using the qualifier "RA-Return Code". This requires that all editors relax edits on SVC01 and SVC06 when the RA qualifier is used.

In the situation where a paper claim is submitted without a procedure code and is not rejected upon receipt, a default procedure code may be required for the 835. Health Plans will need to select one of the following default codes for SVC01 or SVC06 that is appropriate to the type of claim, along with the qualifier "RA-Return Code".
Professional – 99199
Dental – D9999
Institutional – 0949

1.10.2.25 Real-Time Claim Processing

As the healthcare industry continues to evolve in maturing their business processes, the awareness and value of real-time adjudication (RTA) is growing rapidly.

Traditionally, the provider accumulates insurance claims during the day, creates a batch of the day's claims and sends the batch to a clearinghouse or to their practice management system's central servers for delivery to multiple health plans. Based on industry input, the time from submission of the claim until receipt of the health plan's payment can be anywhere from 5 days to 1 month or more.

Once the provider receives payment from the health plan, the office sends a bill to the patient or an additional health plan in order to collect the remainder of the fee for their service.

The patient often takes 90 days or more to send payment. The end result is that it can take in excess of four months for the health care office to receive full payment for their services. The development of high dollar deductible plans and coverage with higher patient liabilities has put additional burden on the providers and their ability to collect the amount owed by the patient.

In an effort to offer better service, some health plans now offer real-time adjudication of health care claims. The provider can submit the claim at the time the service is rendered and receive an immediate response showing the amount anticipated to be paid by the health plan and the amount due from the patient before the patient is ready to check out. In addition to real-time claim adjudication for services rendered, some health plans are also capable of performing real-time predetermination of benefits or estimation and return immediate responses. This functionality allows for accurate and timely treatment planning while the patient is still in the health care office in the event that the costs need to be weighed by the patient.

In real-time mode the sender remains connected while the receiver processes the 837 transaction and returns a 999, 277CA or 835 response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

It is important to note the real-time predetermination of benefits and the real-time claim adjudication are VERY different and have VERY different expected results.

  • Real-time predetermination starts with the 837, followed by the real-time mode predetermination 835. The real-time mode predetermination can be processed through the batch process if mutually agreed to with willing trading partners. Value the CLP02 (Claim Status Code) with "25", (predetermination pricing only-no payment), indicating that the batch ERA claim is a predetermination as done today in the fully batch processing.

A real-time mode claim would be submitted after the patient has received the service(s) in order to adjudicate the claim and determine the health plan and patient responsibility portions.

  • The successful real-time mode claim starts with the standard 837 and returns the real-time mode 835. The anticipated payment reported in the real-time mode 835 is then received in the subsequent batch 835 that reports the actual payment, either via electronic funds transfer (EFT), check or other payment mechanism. In some cases, the batch 835 may result in a zero total payment due to other situations, like reversals and corrections or overpayment recoveries.

X12 has published a number of implementation guides supporting the submission of batch claims (837) and batch payment (835). The purpose is to describe the flow and usage of X12 transactions to support real-time adjudication. This section discusses the use of the real-time mode 837, real-time mode 277CA and the real-time mode 835, with specific references to supporting fields, their suggested field population, and code use to support real-time adjudication.

Figure 1.17 - Real-Time Claim High Level Flow describes the flow and usage of X12 transactions to support real-time adjudication, including the real-time mode 837, real-time mode 277CA and the real-time mode 835, with specific references to supporting fields, their suggested field population, and code use to support real-time adjudication.

Figure 1.17 - Real-Time Claim High Level Flow

Real-Time Claim High Level Flow

The following chart represents 835 elements that require further guidance for use in real-time mode.

Segment/Element Value/Guidance Justification
BPR01 K  
BPR02 Zero BPR02 must be equal to zero to reflect no payment for the transaction
BPR03 C  
BPR04 NON  
BPR16 Date stamp of the interchange envelope.  
TRN02 Unique number between the sender/receiver  
CLP02 1, 2, 3, 4, 25  
CLP07 Payer's actual claim number  
LQ (Loop IDs 2100 and 2110) See RARCs that include a reference to "real-time"  
PLB PLB03-1 04 Real-time adjudication resulting in a payment that will follow separately (Note-this description is as of the publication of this book. Please refer to www.x12.org/codes/ for the most current description.)
 
PLB03-2 Value to the same as TRN02
 
PLB04 Value to the same as CLP04 The adjustment amount negates the amount of the expected payment in CLP04. This offsets the payment amount and results in BPR02 equal to 0.
 

1.10.2.26 Funds Not Available

A health plan may not have the funds/reserves available to pay one or more claims that have been adjudicated. When this scenario occurs, the 835 should not contain claims that reflect a positive payment beyond the total available funds until the additional funds/reserves are available to cover the claim(s) and move the funds to the provider. This will ensure that the 835 can be posted by the provider's accounting system. Actual payment amounts along with adjudication details must be included in the 835.

Please note that this scenario is different than paid claims that are offset by a PLB adjustment that creates a $0 835 (Forward Balance).

1.10.2.27 Claim Status Code Usage

The Claim Status Code required in the 2100 loop, CLP segment, second element (CLP02), is a code that conveys multiple status aspects.

First, it indicates how the payer processed the claim, independent of whether any payment is involved. This may be different than how the claim was submitted (Payer Responsibility Sequence Number Code from the 837 2000B SBR01). For instance, if a claim is submitted as a primary claim, and the payer determines during adjudication that they actually should be the secondary payer CLP02 should contain the code "2", meaning "Processed as Secondary". The claim will then be rejected as if it had been submitted as a secondary claim without including the explanation of benefits from the primary payer. In this situation, the Loop ID 2105 Corrected Priority Payer Name N1 segment is also required to be populated to identify the other payer.

Second, it identifies whether the claim was or wasn't forwarded to a subsequent payer. All of the processing levels come with two possible concepts. One just identifies the processing level (like primary or secondary). The second also identifies additional action by the payer by including "Forwarded to Additional Payer(s)".

Third, there are claim status values that indicate actions not directly related to the processing of a claim. These include values for predetermination of benefits and reversals of prior processing. This also includes situations where the patient cannot be identified by the payer within their system, making processing impossible. Without being able to identify the patient, the payer cannot apply any benefits or contracts to the claim.

Reporting requirements:

  1. Always report using a code that identifies how the payer processed the claim (i.e. - primary, secondary, predetermination, reversal), not how it was submitted.
  2. Claims where the patient can't be identified as the payer's insured can't be processed, since there is no way to identify whether the payer is primary, secondary, etc. Always report using a code that identifies that the claim was not processed (23 - Not Our Claim, Forwarded to Additional Payer(s) or 35 – Patient/subscriber not recognized).
  3. In cases where the claim is forwarded to another payer, always report using a code that identifies that aspect as well as the processing.

2. Transaction Set

NOTE
See X12 documents X12.5, X12.6, and X12.59 to review transaction set structure, including descriptions of segments, levels, and loops.

2.1 Presentation Examples

The 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:

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.

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.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.

"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, requested or rejected by the receiver when the condition is not applicable. Transmission of this data is solely at the sender's discretion when the stated condition does not apply.

"Required when <explicit condition statement>. If not required by this implementation guide, do not send."

The data qualified by such a situational rule must not be sent except as described in the explicit condition statement.

2.2.1.1 Determining Transaction Compliance with Industry Usage Requirements

A transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, 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.

Industry Usage

Business
Condition
is

Item
is

Transaction
Complies with
Implementation
Guide?

Required

N/A

Sent

Yes

Not Sent

No

Not Used

N/A

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.)

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.)

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.

3. Examples

Business scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario.

 

Appendix A. External Code Sources

Prior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer.

Read more about Glass here: https://glasshelp.x12.org/.

Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner.

 

B.1.1 X12 Referenced and Related Standards

This technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report.

The following standards are required to interpret, understand, and use this technical report:

  • X12.5 - Interchange Control Structure
  • X12.6 - Application Control Structure

The following guideline is useful to interpret, understand, and use this technical report:

  • Compliance in X12

The following reference model is useful to interpret, understand, and use this technical report:

  • Acknowledgment Reference Model

All of the documents above are available online using links to X12's Online Viewer.

 

B.1.1.1 Transmission Control Schematic

Refer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications.

Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment, and a functional group is terminated by a group end segment. One or more functional groups are 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

 

B.1.1.2 Constraints applicable to the suite of TR3s

Refer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums.

Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below.

 

B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification

The current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters.

 

B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount

For implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of 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 that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

  • 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 Decimal

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

Appendix D. Change Summary

This Implementation Guide (008020X322) defines the X12 requirements for the Health Care Claim Payment Advice. It is based on version/release/subrelease 008020 of the X12 standards.