Healthcare EDI 837: Claims Submission Guide for Providers

The EDI 837 is the standard electronic format for submitting healthcare claims from providers to payers. Every time a physician’s office bills an insurance company for a patient visit, a hospital submits a facility claim for an inpatient stay, or a dentist files for a procedure – an 837 transaction carries that claim data. It is the starting point of the healthcare revenue cycle’s electronic backbone, and getting it right determines how quickly and accurately providers get paid.

The 837 is formally known as the Health Care Claim transaction, defined by the ASC X12 standard and mandated by HIPAA for electronic claims submission. There are three variants – 837P (Professional), 837I (Institutional), and 837D (Dental) – each designed for a different provider type and claim format. This guide covers the 837’s structure, submission workflow, common rejection codes, and how the 837 connects to the 835 remittance response.

What Is EDI 837?

EDI 837 (Electronic Data Interchange 837) is an X12 transaction set that providers use to submit claims to health insurance payers. It contains all the information a payer needs to adjudicate the claim:

• Patient demographics and insurance information
• Provider identification (NPI, Tax ID)
• Diagnosis codes (ICD-10-CM/PCS)
• Procedure codes (CPT, HCPCS, CDT)
• Dates of service
• Charges and units
• Place of service
• Referring and rendering provider information
• Prior authorization numbers (when applicable)

The 837 replaces the paper CMS-1500 form (for professional claims) and UB-04 form (for institutional claims). Every data element on those paper forms has a corresponding location in the 837 transaction.

HIPAA Mandate

HIPAA requires all covered entities that submit claims electronically to use the X12 837 format. The current mandated version is 005010, with specific implementation guides:

• 837P: 005010X222A1 (Professional)
• 837I: 005010X223A2 (Institutional)
• 837D: 005010X224A2 (Dental)

Providers cannot use proprietary claim formats for electronic submission. Payers must accept and process compliant 837 transactions.

837P vs 837I vs 837D

The three 837 variants serve different segments of the healthcare industry. Understanding which to use is the first step in claims submission.

837P (Professional)

The 837P is used by physicians, outpatient facilities, ambulatory surgery centers, and other professional providers. It maps to the paper CMS-1500 claim form and covers:

• Office visits
• Outpatient procedures
• Laboratory services (when billed by the ordering provider)
• Durable medical equipment
• Home health services
• Ambulance services

The 837P is the most commonly used variant. Most provider billing systems generate 837P transactions by default.

837I (Institutional)

The 837I is used by hospitals, skilled nursing facilities, home health agencies, and other institutional providers. It maps to the paper UB-04 (CMS-1450) claim form and covers:

• Inpatient stays
• Outpatient hospital services
• Emergency department visits
• Rehabilitation facilities
• Psychiatric facilities
• Hospice services

The 837I includes elements specific to institutional billing that do not exist in the 837P: revenue codes, occurrence codes, condition codes, value codes, and the Diagnosis Related Group (DRG) for inpatient claims.

837D (Dental)

The 837D is used by dental providers. It maps to the ADA Dental Claim Form and includes dental-specific elements like tooth numbers, tooth surfaces, oral cavity areas, and CDT (Current Dental Terminology) procedure codes.

Key Differences

837 File Format and Structure

Like all X12 transactions, the 837 uses a hierarchical segment-based structure with envelopes, loops, and segments.

Envelope Structure

The 837 uses the same three-layer envelope as other X12 transactions:

ISA*00*          *00*          *ZZ*PROVIDER_ID    *ZZ*PAYER_ID       *260327*1200*^*00501*000000001*0*P*:~
GS*HC*PROVIDER_ID*PAYER_ID*20260327*1200*1*X*005010X222A1~
ST*837*0001*005010X222A1~

  [Transaction content — claims, subscribers, service lines]

SE*52*0001~
GE*1*1~
IEA*1*000000001~

• ISA/IEA: Interchange envelope with sender/receiver identification and delimiters.
• GS/GE: Functional group. GS*HC identifies this as a Health Care Claim functional group. The version identifier (005010X222A1) specifies which 837 variant.
• ST/SE: Transaction set containing one batch of claims.

Hierarchical Levels (HL Loops)

The 837 uses Hierarchical Level (HL) segments to establish parent-child relationships between billing providers, subscribers (insurance holders), and patients.

HL*1**20*1~        [Billing Provider]
HL*2*1*22*1~       [Subscriber (patient = subscriber)]
HL*3*2*23*0~       [Patient (dependent, if different from subscriber)]

• HL*1 (Level 20 – Information Source): The billing provider or billing service.
• HL*2 (Level 22 – Subscriber): The insurance subscriber. If the patient is the subscriber, the claim data is attached here.
• HL*3 (Level 23 – Patient): Used only when the patient is a dependent (child, spouse) and different from the subscriber.

CLM Loop (Claim Information)

The CLM segment is the heart of the 837. It identifies a single claim:

CLM*CLAIM001*350.00***11:B:1*Y*A*Y*Y~

Key fields:

• CLM01: Patient account/claim number (CLAIM001). This is your internal reference and will be returned in the 835’s CLP01.
• CLM02: Total claim charge amount (350.00)
• CLM05: Place of service, facility code qualifier, and claim frequency. 11:B:1 means place of service 11 (office), facility code qualifier B, and claim frequency 1 (original claim).

DTP Segments (Date/Time)

DTP segments carry dates throughout the 837:

DTP*472*D8*20260315~            [Service date - single (837P service line)]
DTP*434*RD8*20260310-20260315~  [Statement date range (837I claim-level)]
DTP*454*D8*20260301~            [Initial treatment date]
DTP*431*D8*20260301~            [Onset of current illness/symptom]

• DTP01: Date/time qualifier. Key values: 472 = Service Date (837P service-line), 434 = Statement Date range (837I claim-level), 454 = Initial Treatment Date, 431 = Onset of Current Illness or Symptom.
• DTP02: Format (D8 = single date CCYYMMDD, RD8 = date range)
• DTP03: Date value

SBR Loop (Subscriber Information)

The SBR segment identifies the patient’s insurance coverage:

SBR*P*18*GROUP123******CI~

• SBR01: Payer responsibility (P = primary, S = secondary, T = tertiary)
• SBR02: Individual relationship code (18 = self, 01 = spouse, 19 = child)
• SBR03: Group or policy number
• SBR09: Claim filing indicator code (CI = commercial insurance, MA = Medicare Part A, MB = Medicare Part B, MC = Medicaid)

NM1 Segments (Name/Identification)

NM1 segments identify the various entities involved in the claim:

NM1*85*1*SMITH*JAMES*A***XX*1234567890~    [Billing Provider]
NM1*87*2*WEST PALM MEDICAL GROUP*****XX*9876543210~  [Pay-To Provider]
NM1*IL*1*DOE*JOHN****MI*MEMBER001~         [Subscriber]
NM1*82*1*JONES*SARAH*B***XX*5678901234~    [Rendering Provider]
NM1*DN*1*WILLIAMS*ROBERT*C***XX*4567890123~  [Referring Provider]

• NM1*85: Billing provider (who is billing)
• NM1*87: Pay-to provider (who receives payment, if different)
• NM1*IL: Insured/subscriber
• NM1*82: Rendering provider (who performed the service)
• NM1*DN: Referring provider

SV1/SV2 Loops (Service Line)

Service lines detail individual procedures within a claim. The 837P uses SV1 segments; the 837I uses SV2 segments.

837P Service Line (SV1):

SV1*HC:99214*150.00*UN*1*11**1:2~
SV1*HC:85025*75.00*UN*1*11**3~

• SV101: Procedure code (HC:99214 = CPT 99214, office visit level 4)
• SV102: Line item charge amount
• SV103: Unit of measurement (UN = unit)
• SV104: Quantity/units of service
• SV105: Place of service code
• SV107: Diagnosis code pointer (references the DX codes in the HI segment)

837I Service Line (SV2):

SV2*0250*HC:85025*75.00*UN*1~

• SV201: Revenue code (0250 = pharmacy)
• SV202: Procedure code
• SV203: Line item charge amount

HI Segment (Diagnosis Codes)

The HI segment carries diagnosis codes for the claim:

HI*ABK:J06.9*ABF:R50.9~

• ABK: ICD-10-CM principal diagnosis (J06.9 = acute upper respiratory infection)
• ABF: ICD-10-CM additional diagnosis (R50.9 = fever, unspecified)

837 EDI File Structure: Complete Loop Reference

Every loop the 5010 professional claim (005010X222A1) can carry, in the order it appears. Rejection reports quote these numbers, so this is the table to keep open when a 277CA points at “loop 2010BA”.

Institutional differences (837I, 005010X223A2). The skeleton is the same through 2300. Inside the claim, institutional files add CL1 (admission type, source, patient status) and use SV2 service lines carrying revenue codes with the CPT or HCPCS as a secondary element. Operating, attending, and other provider loops sit at 2310A through 2310F rather than 2310A through 2310D. Dental files (837D, 005010X224A2) use SV3 service lines plus TOO segments for tooth and surface.

Where claims actually break. Loops 2010BA and 2010BB (subscriber and payer identity) produce most 277CA rejections, and 2400 or 2430 produce most balancing errors on coordination-of-benefits claims, because the line-level adjudication amounts have to reconcile with the claim-level AMT.

Complete 837P Example

Here is a simplified but complete 837P for a single professional claim:

ISA*00*          *00*          *ZZ*PROVIDER_ID    *ZZ*CLEARINGHOUSE  *260327*1200*^*00501*000000001*0*P*:~
GS*HC*PROVIDER_ID*CLEARINGHOUSE*20260327*1200*1*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH001*20260327*1200*CH~
NM1*41*2*WEST PALM MEDICAL GROUP*****46*123456789~
PER*IC*BILLING DEPT*TE*5615551234~
NM1*40*2*ACME CLEARINGHOUSE*****46*987654321~
HL*1**20*1~
NM1*85*2*WEST PALM MEDICAL GROUP*****XX*1234567890~
N3*100 MEDICAL DR~
N4*WEST PALM BEACH*FL*334010000~
REF*EI*123456789~
HL*2*1*22*0~
SBR*P*18*GROUP123******CI~
NM1*IL*1*DOE*JOHN*A***MI*MEMBER001~
N3*123 MAIN ST~
N4*WEST PALM BEACH*FL*334010000~
DMG*D8*19800115*M~
NM1*PR*2*ACME HEALTH PLAN*****PI*PAYER001~
CLM*CLM001*225.00***11:B:1*Y*A*Y*Y~
HI*ABK:J06.9~
NM1*82*1*SMITH*JAMES*A***XX*1234567890~
SV1*HC:99214*150.00*UN*1*11**1~
DTP*472*D8*20260315~
SV1*HC:85025*75.00*UN*1*11**1~
DTP*472*D8*20260315~
SE*30*0001~
GE*1*1~
IEA*1*000000001~

This 837P submits a single claim (CLM001) for patient John Doe with two service lines: an office visit (99214, $150) and a CBC lab test (85025, $75), both performed on March 15, 2026, at an office setting (POS 11), with a diagnosis of acute upper respiratory infection (J06.9).

837 Claim Submission Workflow

Claims do not go directly from the provider to the payer. The typical workflow involves several intermediaries and checkpoints.

Provider to Clearinghouse to Payer

1. Claim generation. The provider’s practice management system (PMS) or EHR generates an 837 transaction from the encounter data. Most PMS systems batch claims – accumulating charges throughout the day and generating a single 837 file containing multiple claims at end-of-day.

2. Clearinghouse submission. The 837 is transmitted to a clearinghouse via SFTP, AS2, or a web portal. Major clearinghouses include Availity, Change Healthcare (now Optum), Trizetto, and Office Ally.

3. Clearinghouse scrubbing. The clearinghouse validates the 837 against X12 syntax rules, payer-specific requirements, and common billing errors. Claims that fail scrubbing are rejected back to the provider with error codes. Claims that pass are forwarded to the appropriate payer.

4. Payer receipt. The payer receives the 837 from the clearinghouse and generates a 999 (Implementation Acknowledgment) confirming receipt.

5. Adjudication. The payer processes the claim against the patient’s benefit plan, verifying eligibility, applying allowed amounts, and determining payment.

6. Remittance. The payer generates an 835 remittance advice containing the payment decision and sends it back through the clearinghouse to the provider.

Real-Time vs Batch Submission

Batch submission is the traditional model. Claims accumulate and are submitted in batches – typically daily. The 835 response arrives 7-21 days later after the payer completes adjudication. Most claims are still processed in batch mode.

Real-time submission (also called real-time adjudication) is available from some payers for certain claim types. The provider submits a single claim, and the payer returns an adjudication response within seconds. This is most common for:

• Eligibility verification (270/271 transactions, often preceding the 837)
• Simple professional claims with no medical review required
• Dental claims

Real-time adjudication reduces the payment cycle from weeks to seconds but requires direct payer connectivity and is not universally available.

Acknowledgments and Responses

Several response transactions follow an 837 submission. Each lands at a different point in the lifecycle and answers a different question.

The 999 confirms that the file was syntactically valid X12. The 277CA confirms that individual claims were accepted for processing. Neither guarantees payment – they only confirm receipt and initial validation.

Common 837 Rejection Codes and Fixes

Claims are rejected at two stages: the clearinghouse (pre-adjudication) and the payer (post-adjudication). Each has different error patterns.

Clearinghouse Rejections

These are X12 syntax and data quality errors caught before the claim reaches the payer.

Payer Rejections and Denials

These are adjudication-level rejections returned in the 277CA or 835.

Reducing Rejection Rates

The most effective strategies for reducing 837 rejections:

1. Verify eligibility before submission. Use a 270/271 transaction to confirm the patient’s coverage, effective dates, and member ID before generating the 837.
2. Scrub claims internally. Run claims through an internal rules engine that checks for common errors before sending to the clearinghouse.
3. Keep code sets current. ICD-10, CPT, and HCPCS codes change annually. Use current code sets and update them on October 1 (ICD-10) and January 1 (CPT/HCPCS).
4. Monitor rejection patterns. Track rejections by code and payer. If a specific payer consistently rejects for the same reason, there may be an enrollment or configuration issue to resolve.
5. Automate authorization tracking. Denials for missing authorization (CARC 197: “Precertification/authorization/notification/pre-treatment absent”) are among the most common and most preventable. Automate authorization checks during scheduling and prior to claim submission.

The 837 to 835 Round-Trip

The 837 and 835 form a matched pair. The claim number you assign in the 837’s CLM01 field is returned in the 835’s CLP01 field, creating a traceable link between submission and payment.

Matching Claims to Payments

Designing your claim numbering scheme thoughtfully makes 835 processing significantly easier. Use unique, sequential claim numbers in CLM01 that directly reference records in your billing system.

Tracking the Full Lifecycle

For complete revenue cycle visibility, track each claim through every stage:

1. 837 generated – Claim created with unique claim number
2. 837 submitted – File sent to clearinghouse (log date, batch number)
3. 999 received – Syntax acceptance confirmed
4. 277CA received – Claim accepted for adjudication (or rejected)
5. 835 received – Payment decision received
6. Payment posted – Amounts applied to patient account
7. Balance resolved – Patient billed, payment collected, or balance written off

Gaps in this lifecycle (a claim with no 999, a 999 with no 277CA, a 277CA with no 835) indicate processing issues that need investigation.

Clearinghouse Connectivity

The clearinghouse is the intermediary between providers and payers. Choosing and integrating with a clearinghouse is a critical technical and business decision.

What Clearinghouses Do

• Format validation: Verify X12 syntax compliance before forwarding to payers.
• Payer routing: Route claims to the correct payer based on payer ID.
• Scrubbing: Check claims against payer-specific rules and NCCI edits.
• Translation: Handle format differences between the provider’s system and individual payer requirements.
• Aggregation: Consolidate 835 remittances from multiple payers into a single delivery.
• Reporting: Provide claim status dashboards and rejection analytics.

Connectivity Options

Most practice management systems include built-in clearinghouse integrations. For custom integrations or high-volume scenarios, SFTP and AS2 are the standard protocols.

Major Clearinghouses

The healthcare clearinghouse market is dominated by a few major players: Availity (largest by transaction volume), Change Healthcare/Optum, Trizetto (Cognizant), Waystar, and Office Ally. Each has different strengths in payer coverage, claim scrubbing capabilities, and reporting features. Selection typically depends on which payers the provider bills most frequently and what integrations the provider’s PMS supports.

Next Steps

The EDI 837 is the foundation of electronic claims processing in healthcare. Whether you are implementing a new billing system, integrating with a clearinghouse, or optimizing your claims submission workflow, understanding the X12 structure and submission pipeline is essential for clean claims and fast payment.

• CMS Interoperability Services – We build claims processing pipelines, clearinghouse integrations, and payer connectivity solutions.
• Healthcare EDI 835: Remittance Advice Guide – Understand the 835 remittance response that follows your 837 claim submission.
• Healthcare Interoperability Consulting – Comprehensive integration strategy spanning EDI, HL7, and FHIR.