8.4 Claim Submission (EDI 837), Remittance (EDI 835) & Revenue Cycle
Key Takeaways
- The EDI 837 Health Care Claim standard is used for electronic billing, formatted as EDI 837P for professional services and EDI 837I for institutional services.
- Clearinghouse claim scrubbers audit billing batches against payer rules, catching demographic errors, missing code linkage, and NCCI edits prior to claim transmission.
- The EDI 835 Electronic Remittance Advice (ERA) reports claim adjudication details, allowed amounts, contractual adjustments, and patient financial responsibility.
- Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs) explain specific line-item payment reductions or claim denials.
- Effective revenue cycle management requires systematic denial management workflows, secondary insurance billing, and clear patient statement generation.
Claim Submission (EDI 837), Remittance (EDI 835) & Revenue Cycle
The final phase of the healthcare revenue cycle transforms validated clinical encounter data into financial reimbursement. Back-end revenue cycle operations focus on electronic claim submission, clearinghouse claim scrubbing, payment posting from Electronic Remittance Advice (ERA) files, denial management, and patient billing statement processing. Mastery of these electronic transaction standards and administrative workflows is essential for Certified Electronic Health Records Specialists.
1. Electronic Claim Standards: EDI 837P & EDI 837I
Under HIPAA administrative simplification regulations, health plans must accept standardized electronic health care claims. The EDI 837 Health Care Claim is the electronic format used to submit health care billing claims directly to insurance payers or clearinghouses.
Professional vs. Institutional Claims
- EDI 837P (Professional Claim): Used by physicians, outpatient clinics, group practices, and allied health professionals to bill for professional services. The EDI 837P is the electronic equivalent of the paper CMS-1500 claim form.
- EDI 837I (Institutional Claim): Used by hospitals, inpatient facilities, skilled nursing facilities, and ambulatory surgical centers to bill for facility fees. The EDI 837I is the electronic equivalent of the paper UB-04 (CMS-1450) claim form.
Mandatory Claim Fields on EDI 837P
- Billing Provider & Rendering Provider NPI: National Provider Identifier 10-digit numbers.
- Place of Service (POS) Codes: Standardized 2-digit numbers (e.g.,
11= Office;21= Inpatient Hospital;22= Outpatient Hospital). - Diagnosis Codes (ICD-10-CM): Primary and secondary diagnoses mapped with diagnosis pointers.
- Procedural Codes (CPT/HCPCS): Procedure codes with units, line charges, and CPT modifiers.
- Prior Authorization Number: Pre-certification approval string when required by the plan.
| Claim Format | Paper Equivalent | Provider / Setting Type | Primary Purpose |
|---|---|---|---|
| EDI 837P | CMS-1500 | Outpatient Physicians & Clinics | Bills professional services and office visits |
| EDI 837I | UB-04 (CMS-1450) | Hospitals & Inpatient Facilities | Bills institutional facility fees and bed charges |
2. Clearinghouse Operations & Claim Scrubbing
An healthcare clearinghouse is a specialized intermediary software entity that receives billing claim batches from provider PM/EHR systems, audits (scrubs) the data for errors, formats the claims into payer-specific EDI specifications, and transmits clean claims to insurance payers via secure electronic protocols (SFTP/HTTPS).
Claim Scrubbing
Claim scrubbing is the automated auditing process performed by clearinghouse software prior to transmitting claims to payers. Scrubbers validate claims against federal rules and payer-specific edits, checking for:
- Valid patient demographic data (matching subscriber ID format).
- Valid rendering and billing provider NPI numbers.
- Active insurance payer IDs.
- Accurate ICD-10-CM and CPT code formatting and linkage.
- NCCI procedure-to-procedure unbundling edits.
Claim Rejections vs. Claim Denials
- Claim Rejection (Pre-adjudication): Occurs at the clearinghouse or payer front-end portal before the claim enters the payer's adjudication system. Caused by formatting errors, missing data fields, or invalid policy numbers. Rejections are not formally adjudicated; they must be corrected and resubmitted immediately.
- Claim Denial (Post-adjudication): Issued by the insurance payer after the claim has been fully adjudicated. Denials occur when the payer determines a service is non-covered, medically unnecessary, or lacks prior authorization. Denials require formal appeals or corrected claim submissions.
3. Electronic Remittance Advice (EDI 835 ERA) & EOB
Once a payer adjudicates a claim, it issues a payment determination and generates an EDI 835 Health Care Claim Payment/Advice file (commonly called an Electronic Remittance Advice or ERA). The paper document sent to the patient explaining the same adjudication results is the Explanation of Benefits (EOB).
Financial Components of an EDI 835 ERA
- Billed Amount: Total gross fee charged by the provider.
- Allowed Amount: Contracted maximum dollar amount the provider has agreed to accept per network agreement.
- Contractual Adjustment (Write-off): The difference between the Billed Amount and the Allowed Amount for in-network providers (Billed Amount − Allowed Amount = Contractual Write-off).
- Paid Amount: Actual net check or electronic funds transfer (EFT) amount issued by the payer.
- Patient Financial Responsibility: The remaining balance owed by the patient, broken down into copayment, deductible, and coinsurance amounts.
Standardized Denial Codes: CARCs & RARCs
To explain payment reductions or line-item denials, payers include standardized code sets in the EDI 835 file:
- Claim Adjustment Reason Codes (CARCs): Explain why a claim or line item was paid differently than billed (e.g., CARC 45 = Charge exceeds fee schedule/maximum allowable amount; CARC 16 = Claim/service lacks information or has error(s)).
- Remittance Advice Remark Codes (RARCs): Provide additional, detailed explanations supplementary to CARCs.
4. Payment Posting & Secondary Billing Workflows
Automated Payment Posting
Modern PM/EHR systems utilize ERA auto-posting. When the EDI 835 file is received electronically, the PM system automatically parses payment lines, applies contractual write-offs, updates patient account balances, and flags secondary insurance claims.
Secondary Billing Workflow
If a patient has secondary coverage (e.g., Medicare primary and a commercial Medigap secondary plan):
- Primary payer adjudicates the EDI 837P claim and generates an EDI 835 ERA.
- The PM system posts the primary payment and contractual adjustment.
- The PM system automatically generates a secondary EDI 837P claim, attaching primary adjudication data (primary allowed amount, primary paid amount, and remaining patient responsibility balance).
- Secondary payer adjudicates the remaining balance.
Patient Billing Statement Generation
Once all primary and secondary insurance payments and contractual adjustments have been posted, any remaining balance represents patient responsibility. The PM system generates an itemized patient statement detailing:
- Dates of service and descriptions of procedures.
- Total charges and insurance payments/adjustments applied.
- Clear itemization of remaining patient copay, deductible, or coinsurance balance.
- Due dates, payment portal links, and financial hardship/payment plan policies.
An EHR specialist receives an EDI 835 Electronic Remittance Advice (ERA) file indicating that a claim line item was partially paid, with a CARC 45 code stating the charge exceeds the contracted allowed amount. For a contracted in-network provider, how must the difference between the total billed charge and the allowed amount be handled?
What is the primary operational difference between a claim rejection and a claim denial?
A billing department receives an electronic file from a commercial payer detailing approved claim payment amounts, CARC denial codes, contractual write-offs, and remaining patient copay responsibilities for an entire batch of encounters. Which HIPAA EDI transaction set is being utilized?