<img alt="" src="https://secure.leadforensics.com/150446.png " style="display:none;">
Go to top icon

EDI Unleashed – Series 6

Supriya Sonavane Apr 01, 2013

Health Care Remittance Advice Electronic Data Interchange EDI 835 Healthcare EDI Health Care Claim Payment Technology

We have discussed in previous blog about EDI 837 message in EDI. Let’s look at EDI 835 transaction.

The EDI 835 transaction deals with Health Care Claim Payment and Remittance Advice.

It has been specified by HIPAA 5010 requirements for the electronic transmission of healthcare payment and benefit information.

Healthcare insurance plans use EDI 835 to send payments details to healthcare providers, to provide Explanations of Benefits (EOBs), or both. When a healthcare service provider sends an 837 Health Care Claim to the insurance plan, the insurance plan responds by sending 835 to detail the payment to that claim, which includes:

  • What charges were paid, reduced or denied.
  • Whether there was a deductible, co-insurance, co-pay, etc.
  • Any bundling or splitting of claims or line items.
  • How the payment was made, such as through a clearinghouse.

The 835 Implementation Guide recommends a maximum of 10,000 CLP (Claim Payment) Segments per transaction.
Claim payments are made based on the NPI and Tax ID Number. Depending on the reimbursement arrangement, multiple providers may be paid under their group NPI and Tax ID. Therefore, when a provider group requests an 835, by default all provider payments linked to the group NPI will appear on the 835. Note that all registered NPIs will be returned on the 835.

The format of the 835 file will show multiple checks and/or payment information tied to the provider group or individual provider on a given day in one or multiple ERA files. Checks and/or payment information can be bundled and uniquely identified within the same 835 file.

All 835 Transactions are enclosed in transmission level ISA/IEA envelopes and, within transmissions, functional group level GS/GE envelopes.

Key Segments which are a part of 835P message are as follows:

BPR: Beginning Segment for Payment Order/Remittance Advice
TRN: REASSOCIATION TRACE NUMBER
CUR: To specify the currency (dollars, pounds, francs, etc.) used in a transaction
REF: Reference Identification Qualifier
DT: Date/Time
N1: Payer Identification/Patient Name
N3: Payer Address
N4: Geographic Address
PER: Administrative Communications Contact
LX: Provide a looping structure and logical grouping of claim payment information
TS3: Provider level control information
TS2: Provide supplemental summary control information by provider fiscal year and bill type
CLP: To supply information common to all services of a claim
CAS: Provides adjustment reason codes and amounts as needed for an entire claim or for a particular service within the claim being paid
NM1: Insured’s Name
MIA: Provides claim-level data related to the adjudication of Medicare inpatient claims
MOA: To convey claim-level data related to the adjudication of Medicare claims not related to an inpatient setting
AMT: To indicate the total monetary amount
QTY: To specify quantity information
SVC: To supply payment and control information to a provider for a particular service
LQ: Code to transmit standard industry codes

As a remittance advice, the 835 provides detailed payment information relative to a 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 “justification” for the payment, as well as input to the payee’s (Provider) patient accounting system/accounts receivable (A/R) and general ledger applications.

To ensure HIPAA compliance, editing is performed on the 835 transaction as it is routed through the Enterprise EDI Gateway/Clearinghouse. Successful outbound routing to the 835 trading partner (ex. Provider) depends on the balancing of the file where the total payment must agree with the remittance information detailing that payment.

The amounts reported in the file must balance at three different levels; the service line, the claim, and the transaction. When service payment information is provided, the submitted service charge (SVC02) minus the sum of all monetary adjustments (CAS segments) must equal the amount paid for the service line (SVC03).

Similarly within the claim payment loop, the submitted charge for the claim (CLP03) minus the sum of all monetary adjustments (CAS segments) must equal the claim paid amount (CLP04). The total claim charge (CLP03) must balance the sum of the related service charges (SVC02), if applicable. *Monetary amounts in the AMT segments convey information only; they do not affect the financial balancing of the transaction.

Further balancing within the transaction ensures that the sum of all claim payments (CLP04) minus the sum of all provider level adjustments (PLB segments) equals the total payment amount (BPR02). All balancing measures must be met in order for an 835 fi le to be delivered to the Gateway.

We are now acquainted with the core EDI messages and significance of each. We will take a look at the sources of generating EDI messages in the next blog.

Similar Blog

e-Zest is a leading digital innovation partner for enterprises and technology companies that utilizes emerging technologies for creating engaging customers experiences. Being a customer-focused and technology-driven company, it always helps clients in crafting holistic business value for their software development efforts. It offers software development and consulting services for cloud computing, enterprise mobility, big data and analytics, user experience and digital commerce.