835 Transaction Set Listing
008020X322 Health Care Claim Payment/Advice- Loop 1000A - PAYER IDENTIFICATIONRequired1
- Loop 1000B - PAYEE IDENTIFICATIONRequired1
- Loop 2000 - HEADER NUMBERSituational>1
- Loop 2100 - CLAIM PAYMENT INFORMATIONRequired>1
- Loop 2105 - CORRECTED PRIORITY PAYER NAMESituational10
- Loop 2110 - SERVICE PAYMENT INFORMATIONSituational999
ISA - INTERCHANGE CONTROL HEADER
- 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.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*HP - FUNCTIONAL GROUP HEADER
ST*835 - TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.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.
BPR - FINANCIAL INFORMATION
- P0607
If either BPR06 or BPR07 is present, then the other is required. - C0809
If BPR08 is present, then BPR09 is required. - P1213
If either BPR12 or BPR13 is present, then the other is required. - C1415
If BPR14 is present, then BPR15 is required. - P1819
If either BPR18 or BPR19 is present, then the other is required. - C2021
If BPR20 is present, then BPR21 is required.
- 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.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
For information on card payment processing, see sections 1.10.1.2.6, 1.10.1.4, and 1.10.2.3.
For information on card payment processing, see sections 1.10.1.2.6, 1.10.1.4, and 1.10.2.3.
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.
TRN*1 - REASSOCIATION TRACE NUMBER
- 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. - See 1.10.2.3, Reassociation of Dollars and Data, for additional information.
- 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.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- 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.
- 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
- C0807
If CUR08 is present, then CUR07 is required. - C0907
If CUR09 is present, then CUR07 is required. - L101112
If CUR10 is present, then at least one of CUR11 or CUR12 are required. - C1110
If CUR11 is present, then CUR10 is required. - C1210
If CUR12 is present, then CUR10 is required. - L131415
If CUR13 is present, then at least one of CUR14 or CUR15 are required. - C1413
If CUR14 is present, then CUR13 is required. - C1513
If CUR15 is present, then CUR13 is required. - L161718
If CUR16 is present, then at least one of CUR17 or CUR18 are required. - C1716
If CUR17 is present, then CUR16 is required. - C1816
If CUR18 is present, then CUR16 is required. - L192021
If CUR19 is present, then at least one of CUR20 or CUR21 are required. - C2019
If CUR20 is present, then CUR19 is required. - C2119
If CUR21 is present, then CUR19 is required.
REF*EV - RECEIVER IDENTIFICATION
At least one of REF02 or REF03 is required.
- Receiver 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.
REF*AFC - CARD SECURITY VERIFICATION CODE
At least one of REF02 or REF03 is required.
DTM*405 - PRODUCTION DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
DTM*036 - CARD EXPIRATION DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
N1*PR - PAYER IDENTIFICATION
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
- Use this N1 loop to provide the name/address information for the payer.
- The payer's secondary identifying reference number is provided in the 1000A REF Additional Payer Identification, if necessary.
N3 - PAYER ADDRESS
N4 - PAYER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF - ADDITIONAL PAYER IDENTIFICATION
At least one of REF02 or REF03 is required.
REF*EO - TRANSACTION CREATOR IDENTIFIER
At least one of REF02 or REF03 is required.
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.
- This segment is not used by third parties between the payer and the payee.
- 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.
PER*CX - PAYER BUSINESS CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
PER*BL - PAYER TECHNICAL CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
PER*IC - PAYER WEBSITE CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
AND
more details are available via the payer Website.
If not required by this implementation guide, do not send.
- 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.
- 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.
N1*PE - PAYEE IDENTIFICATION
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - PAYEE ADDRESS
N4 - PAYEE CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF - PAYEE ADDITIONAL IDENTIFICATION
At least one of REF02 or REF03 is required.
REF*TJ - PAYEE TAX IDENTIFICATION
At least one of REF02 or REF03 is required.
RDM - REMITTANCE DELIVERY METHOD
LX - HEADER NUMBER
- The purpose of LX01 is to provide an identification of a particular grouping of claims for sorting purposes.
- 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.
TS3 - PROVIDER SUMMARY INFORMATION
- TS301 identifies the subsidiary provider.
- The remaining mandatory elements (TS302 through TS305) must be valid with appropriate data, as defined by the TS3 segment.
- Only Medicare uses data elements TS313, TS315, TS317, TS318 and TS320 through TS324. Each monetary amount element pertains to the provider identified in TS301.
- This is the provider number. When the provider has an NPI, this must be the provider's NPI.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- 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.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- The professional component amount must also be reported in the RAS segment with a Claim Adjustment Reason Code value of 89.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
TS2 - PROVIDER SUPPLEMENTAL SUMMARY INFORMATION
- This segment provides summary information specific to an iteration of the LX loop (Table 2).
- Each element represents the total value for the provider/bill type combination in this loop 2000 iteration.
- 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- This is the discharge count produced by PPS PRICER SOFTWARE.
- See TR3 note 2.
- See TR3 note 2.
- See sections 1.10.2.4.2 and 1.10.2.4.6 for additional information.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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.
- See TR3 note 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
If either CLP11 or CLP12 is present, then the other is required.
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.
- 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.
- See 1.10.2.1.2, Claim Balancing, in this implementation guide for additional information.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- See 1.10.2.1.2, Claim Balancing, in this implementation guide for additional information.
- 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.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- 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.
- 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.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- Use this number for the payer's internal control number. This number must apply to the entire claim.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- This number was received in CLM05-01 of the 837 claim.
- 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.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
RAS - CLAIM ADJUSTMENT INFORMATION
- 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.
- See the SVC TR3 Note #2 for details about per diem adjustments.
- 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).
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
See Front Matter Section 1.10.2.4.5, Claim Adjustment Group Code Usage, for additional information.
- P0203
If either C05802 or C05803 is present, then the other is required. - C0403
If C05804 is present, then C05803 is required. - C0504
If C05805 is present, then C05804 is required. - C0605
If C05806 is present, then C05805 is required. - C0706
If C05807 is present, then C05806 is required.
- 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. - This composite identifies the reason for the adjustment of the dollar amount identified in RAS01.
NM1*QC - PATIENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- Any necessary identification number should be provided in NM109.
- 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.
- The Corrected Patient/Subscriber Name NM1 segment identifies the adjudicated Subscriber Name and ID information if different than what was submitted on the claim.
NM1*IL - SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- In the case of Medicare and Medicaid, the insured patient is always the subscriber and this segment is not used.
- 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)
- The Corrected Patient/Subscriber Name NM1 segment identifies the adjudicated Subscriber Name and ID information if different than what was submitted on the claim.
NM1 - CORRECTED PATIENT/SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
NM1*SJ - SERVICE PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
NM1*TT - CROSSOVER CARRIER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- 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.
- When the claim is transferred to more than 1 carrier, use this segment to report all crossover names and reference numbers.
MIA - INPATIENT ADJUDICATION INFORMATION
- Either MIA or MOA may appear, but not both.
- All situational quantities and/or monetary amounts in this segment are required when the value of the item is different than zero.
MOA - OUTPATIENT ADJUDICATION INFORMATION
- Either MIA or MOA may appear, but not both.
- All situational quantities and/or monetary amounts in this segment are required when the value of the item is different than zero.
REF - OTHER CLAIM RELATED IDENTIFICATION
At least one of REF02 or REF03 is required.
REF*F8 - ORIGINAL PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*CE - CLASS OF CONTRACT CODE
At least one of REF02 or REF03 is required.
- P0304
If either C04003 or C04004 is present, then the other is required. - P0506
If either C04005 or C04006 is present, then the other is required.
- 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.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF - SERVICE PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
REF - PAYMENT DETERMINATION METHODOLOGY
At least one of REF02 or REF03 is required.
REF*BLT - ORIGINAL CLAIM INFORMATION
At least one of REF02 or REF03 is required.
Code Description
P Professional
IP Institutional Inpatient
OP Institutional Outpatient
D Dental
RX Pharmacy
- P0304
If either C04003 or C04004 is present, then the other is required. - P0506
If either C04005 or C04006 is present, then the other is required.
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.
REF - CLAIM AUTHORIZATION INFORMATION
At least one of REF02 or REF03 is required.
DTM - STATEMENT DATES
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
- 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.
- When claim dates are not provided, service dates are required for every service line.
- When claim dates are provided, service dates are not required, but if used they override the claim dates for individual service lines.
- For retail pharmacy claims, the Claim Statement Period Start Date is equivalent to the prescription filled date.
- When payment is being made in advance of services, the use of future dates is allowed.
DTM*036 - COVERAGE EXPIRATION DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
DTM*050 - CLAIM RECEIVED DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
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.
DTM*242 - CLEAN CLAIM DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
DTM*439 - CORRECTED ACCIDENT DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
DTM*431 - CORRECTED ONSET OF CURRENT SYMPTOMS OR ILLNESS DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
PER*CX - CLAIM CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
PER - ENTITY SELF-INSURED PLAN / JURISDICTION CONTACT
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
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.
- 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. - 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-".
If PER01 value is 'IC' then this is the jurisdiction/payer name.
PER*CN - WORKERS' COMPENSATION PAYER WEBSITE
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
AMT*B6 - CLAIM ALLOWED AMOUNT
AMT - CLAIM SUPPLEMENTAL INFORMATION
- Use this segment to convey information only. It is not part of the financial balancing of the 835.
- Send/receive one AMT for each applicable non-zero value. Do not report any zero values.
- Supplemental information reported at the Service level (2110 loop) AMT Segment is not repeated at the claim level (2100 loop) AMT Segment.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
QTY - CLAIM SUPPLEMENTAL INFORMATION QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- Use this segment to convey information only. It is not part of the financial balancing of the 835.
- Send one QTY for each non-zero value. Do not report any zero values.
LQ - HEALTH CARE REMARK CODES
If LQ01 is present, then LQ02 is required.
N1*COR - CORRECTED PRIORITY PAYER NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
NM1*GB - OTHER SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
SVC - SERVICE PAYMENT INFORMATION
- 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.
- 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.
- 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.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This is the adjudicated medical procedure information.
- This code is a composite data structure.
- 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.
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
- Use this monetary amount for the submitted service charge amount.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- See section 1.10.2.14.2 for usage information when service lines are split.
- 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.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This code is a composite data structure.
- This is the Submitted Procedure Code information.
- 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.
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
- See Section 1.10.2.4.2 Claim/Service Adjustment Information Segment for Units of Service balancing requirements.
- See section 1.10.2.14.2 for usage information when service lines are split.
DTM - SERVICE DATE
- R020305
At least one of DTM02, DTM03 or DTM05 is required. - C0403
If DTM04 is present, then DTM03 is required. - P0506
If either DTM05 or DTM06 is present, then the other is required.
- Dates at the service line level apply only to the service line where they appear.
- If used for inpatient claims and no service date was provided on the claim then report the through date from the claim level.
- When claim dates are not provided, service dates are required for every service line.
- When claim dates are provided, service dates are not required, but if used they override the claim dates for individual service lines.
- For retail pharmacy claims, the service date is equivalent to the prescription filled date.
- For predetermination claims when the CLP02 value is 25 - Predetermination Pricing Only - No Payment, no dates are supported at either claim or service level.
- When payment is being made in advance of services, the use of future dates is allowed.
RAS - SERVICE ADJUSTMENT INFORMATION
- 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.
- 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.
- 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).
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
See Front Matter Section 1.10.2.4.5, Claim Adjustment Group Code Usage, for additional information.
- P0203
If either C05802 or C05803 is present, then the other is required. - C0403
If C05804 is present, then C05803 is required. - C0504
If C05805 is present, then C05804 is required. - C0605
If C05806 is present, then C05805 is required. - C0706
If C05807 is present, then C05806 is required.
- This composite identifies the reason for the adjustment of the dollar amount identified in RAS01.
- 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.
- A positive value decreases the quantity, and a negative value increases the quantity.
- See section 1.10.2.4.2 for information about quantity balancing.
REF - SERVICE IDENTIFICATION
At least one of REF02 or REF03 is required.
REF - PAYMENT DETERMINATION METHODOLOGY
At least one of REF02 or REF03 is required.
- This is the 'Payment Determination Methodology' identified by the REF01 qualifier used to adjudicate and derive the allowed amount for the service.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF - SERVICE PROVIDER INFORMATION
At least one of REF02 or REF03 is required.
REF*0K - HEALTHCARE POLICY IDENTIFICATION
At least one of REF02 or REF03 is required.
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.
- 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.
- 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).
- This policy segment must not be used to provide a proprietary explanation code or reason for adjustment.
- 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.
- 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.
- 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.
REF - SERVICE AUTHORIZATION INFORMATION
At least one of REF02 or REF03 is required.
AMT*B6 - SERVICE ALLOWED AMOUNT
AMT - SERVICE SUPPLEMENTAL AMOUNT
- This segment is used to convey information only. It is not part of the financial balancing of the 835.
- Supplemental information reported at the Claim level (2100 loop) AMT Segment is not repeated.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
QTY - SERVICE SUPPLEMENTAL QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
LQ - HEALTH CARE REMARK CODES
If LQ01 is present, then LQ02 is required.
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
- TOO✱JP✱12✱L:O~
- TOO✱JO✱10~
PLB - PROVIDER ADJUSTMENT
- P0506
If either PLB05 or PLB06 is present, then the other is required. - P0708
If either PLB07 or PLB08 is present, then the other is required. - P0910
If either PLB09 or PLB10 is present, then the other is required. - P1112
If either PLB11 or PLB12 is present, then the other is required. - P1314
If either PLB13 or PLB14 is present, then the other is required.
- 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.
- The codes and notations under PLB03 and its components apply equally to PLB05, 07, 09, 11 and 13.
- When the provider is a covered entity under the National Provider Identifier (NPI) mandate, this must be the NPI assigned to the provider.
- 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.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- Refer to code list for definition and usage instructions.
- Code Source 967 - Provider Adjustment Reason Codes
- This is the adjustment amount for the preceding adjustment reason.
- Refer to Appendix B.1.1.3 for more information about decimal data elements.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the adjustment amount for the preceding adjustment reason.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the adjustment amount for the preceding adjustment reason.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the adjustment amount for the preceding adjustment reason.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the adjustment amount for the preceding adjustment reason.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the adjustment amount for the preceding adjustment reason.
- 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
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 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:
|
PrefaceX12 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 ScopeFor 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: |
1.2 Version InformationThis 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:
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 UsageThere 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 LimitationsThere 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 UsageThe 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 FlowEach 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 FlowsFigure 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 |
1.5 Business TerminologyTo 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 AcknowledgmentsThe 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 TransactionsThere 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 AgreementsTrading 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 ComplianceThere 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 RequirementsA 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 RegulationsThis 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 RequirementsX12 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 |
1.10.1.1 PaymentThe 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 CheckFigure 1.2 - ERA with Payment by Check |
1.10.1.2.2 ERA and EFT through DFIFigure 1.3 - ERA and EFT through DFI |
1.10.1.2.3 ERA with Payment by Separate EFTFigure 1.4 - ERA with Payment by Separate EFT 835 traveling separate from the dollars in the EFT payment |
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 |
1.10.1.2.5 ERA with Debit EFTFigure 1.6 - ERA with Debit EFT |
1.10.1.2.6 ERA with Payment by CardFigure 1.7 - Card Straight-Through Processing via Card Network Figure 1.8 - 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 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 TransferThe 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:
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 835Section 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 835Given 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):
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 RemittanceAs 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 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 UseThis 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:
Figure 1.11 - 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 |
1.10.2.1 Financial BalancingThe 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 |
1.10.2.1.1 Service Line BalancingFigure 1.12 - Service Line Balancing Segments Although the service payment information is optional, it is REQUIRED for all service lines in a
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:
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) |
1.10.2.1.2. Claim BalancingFigure 1.13 - 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 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 BalancingFigure 1.14 - 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 BalancingAdjustments 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 TrackingFigure 1.15 - 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:
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 |
1.10.2.3 Reassociation of Dollars and DataThe 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 PaymentsOccasionally, 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 UpgradeSince 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 SegmentThe 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 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) UsageA 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 CARC and Remark Code Associations 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 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 CodesStandardized 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 LevelAt 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 LevelAt 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 ReversalsRemark 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 UsageA 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:
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 |
1.10.2.4.6 Institutional-Specific UseWithin 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 ReconciliationIn 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 Example: 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
|
1.10.2.6 Procedure Code Bundling and UnbundlingProcedure 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 Bundling Example
CLP*123456789*1*200*50*70**1234567ABC~ 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
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~ Partial Unbundling 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~ NOTE |
1.10.2.7 Predetermination of BenefitsTables 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 Table 1.1 - Example Adjustments
The projected payment amount is then $550. CLP*1234567890*25*1100*0*250**9012345678~ |
1.10.2.8 Reversals and CorrectionsWhen 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 Example Table 1.2 - Reported Amounts
Original Payment CLP*1234567890*1*100*40*40**12345*********612~ 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 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~ CLP*1234567890*1*100*24*36**67890*********612~ NOTE
|
1.10.2.9 Interest and Prompt Payment DiscountsPayer-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.):
Refers to interest adjustments made as part of the contractual agreement for handling claim obligations beyond the timelines established.
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 Summary
Example
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~ |
1.10.2.10 Capitation and Related Payments or AdjustmentsThe 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 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):
For information about reporting encounters in the 835 see Section 1.10.2.19 - Reporting Encounters in the 835. |
1.10.2.11 Claim SplittingA 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 ProcessingA 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 ClaimThis 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:
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 ClaimThe 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:
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:
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 ConsiderationsSometimes 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.
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:
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.
|
1.10.2.14 Service Line IssuesWhile 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:
|
1.10.2.14.1 Reporting Invalid or Unrecognized Procedure Information (SVC01 / SVC06) in the 835There 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 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 SplittingDuring 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: Examples when service line splitting is necessary include, but are not limited to:
Technical Issues (System Limitations): 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:
Unbundling:
NOTE Splitting Line Requirements:
Example 1 Original Claim
SVC*HC:A*100*100**1~ Example 2 Original Claim
SVC*HC:A*400*400**4~ Line Splitting Across 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:
Original Claim - Patient Control # - 12345
835 for Claim 1 CLP*12345*1*740*740***123456789~ Split Claim: Claim 2
835 for Claim 2 CLP*12345*1*350*350***123456798~ Total of Both Claims: 1090.00 |
1.10.2.15 PPOs, Networks and Contract TypesMany 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 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~ 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~ 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 RecoveryThe 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 RecoveryWhile 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.
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~ Second 835 Reversal and Correction BPR*I*590*C*ACH*CCP*01*123465789*DA*123458*0123456789**01*12345*DA*123456*20180101~ 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 Initial 835 Original: CLP*12345*1*1000*500*300**987654321*11*1*******51~ Second 835 Reversal and Correction BPR*H*0*C*NON************20180101~ 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 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 835The 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 835Encounters (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.
NOTE |
1.10.2.20 Retroactive Claim AdjustmentsSituations 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 MatchingThe 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 PayeeDue 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 AdjudicationClaim 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):
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 IntegrityThe 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". |
1.10.2.25 Real-Time Claim ProcessingAs 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.
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.
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 The following chart represents 835 elements that require further guidance for use in real-time mode.
|
1.10.2.26 Funds Not AvailableA 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 UsageThe 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:
|
2.1 Presentation ExamplesThe 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 Figure 2.2 - Transaction Set Key - Standard Figure 2.3 - Segment Key - Implementation Figure 2.4 - Segment Key - Diagram Figure 2.5 - Segment Key - Element Summary |
2.2.1 Industry UsageIndustry 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).
|
2.2.1.1 Determining Transaction Compliance with Industry Usage RequirementsA 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.
|
2.2.2 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness 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 SourcesPrior 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 StandardsThis 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:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer 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 | ||||
| Â | ||||
B.1.1.2 Constraints applicable to the suite of TR3sRefer 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 IdentificationThe 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 AmountFor 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
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis 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. |