EDI 837 Health Care Claim: 837P, 837I, 837D

The EDI 837 is how almost every US health care claim reaches a payer. A physician's office visit, a hospital emergency department stay and a dental cleaning all travel as 837s, usually through a clearinghouse. The three variants share one loop structure and differ in the claim and service line detail, which is why one guide can cover all three and why a validator has to know which variant it is reading.

This guide covers what the 837 carries, the HL loop structure (2000A, 2000B, 2000C, 2300, 2400), the segments billing and health IT teams map, live examples of an 837P, an 837I and an 837D, how 837s are validated and acknowledged, and how each claim is matched to its 835 payment. It explains the file format only. It is not coding, billing or legal advice; code sets, payer companion guides and your compliance team govern what goes on a claim.

What Is an EDI 837?

An EDI 837 is the Health Care Claim transaction set defined by ASC X12, used by health care providers (or billing services and clearinghouses acting for them) to submit claims and encounter information to health plans. It is the HIPAA standard for health care claims. 45 CFR 162.1102 names three X12 technical reports, one per variant:

Authoritative references for 837 work:

• 45 CFR Part 162, administered by CMS, lists the adopted HIPAA claim standards and the National Provider Identifier (NPI) requirement
• The X12 005010X222A1, X223A2 and X224A2 technical reports (TR3s) define every loop, segment and code for each variant
• Payer and state companion guides, such as the Indiana Department of Health 837I and 837D companion guides, say which situational segments a receiver requires

Who sends it? The provider's practice management or hospital billing system, usually through a clearinghouse.

Who receives it? The health plan, either directly or through the clearinghouse. Coordination-of-benefits claims also go from one payer or provider to a secondary payer.

When is it sent? After the service, once the claim is coded and checked. Most systems batch claims and send files daily.

Why does it matter? A claim the payer cannot accept is a claim that is not paid. Rejections at the 999 or 277CA stage cost days; claims that never arrive cost timely filing.

How the 837 Claim Cycle Works

1. Eligibility. Before or at the visit, the provider checks coverage with a 270 eligibility inquiry and gets a 271 response.
2. Coding and charge entry. Diagnoses (ICD-10-CM), procedures (CPT/HCPCS, CDT for dental, revenue codes for facilities) and charges are entered.
3. Claim build and scrub. The billing system builds the 837 and the clearinghouse runs edits against the TR3 and payer rules.
4. Submission. The 837 file goes to the payer.
5. Acknowledgments. A 999 reports whether the file passed X12 and TR3 validation. A 277CA (claim acknowledgment, 005010X214) reports which claims were accepted into adjudication and which were rejected.
6. Status. While a claim is pending, a 276 claim status request returns a 277 status response.
7. Payment. The payer pays and explains with an 835 remittance advice. CLP01 on the 835 echoes CLM01 from the 837.
8. Correction. Denied or incorrect claims go back as replacement (7) or void (8) claims referencing the payer's claim number.

The 837 Loop Structure

Every 837 variant uses the same HL (hierarchical level) tree. Understanding it is most of the work in reading one.

ST / BHT                       Transaction header
  1000A  NM1*41                Submitter (with PER contact)
  1000B  NM1*40                Receiver
  2000A  HL*n**20*1            Billing provider level
    2010AA NM1*85              Billing provider name, address, tax ID
    2010AB NM1*87              Pay-to address (when different)
    2000B  HL*n*p*22*0|1       Subscriber level, SBR
      2010BA NM1*IL            Subscriber
      2010BB NM1*PR            Payer
      2000C  HL*n*p*23*0       Patient level, PAT (only when the patient is not the subscriber)
        2010CA NM1*QC          Patient
      2300   CLM               Claim (under 2000B, or under 2000C when present)
        2310x NM1              Claim-level providers (referring, rendering, attending, facility)
        2320  SBR              Other payers (coordination of benefits)
        2400  LX + SV1|SV2|SV3 Service lines
          2410 LIN             Drug identification
          2420x NM1            Line-level providers
          2430 SVD + CAS       Prior payer's line adjudication (secondary claims)
SE

HL04 (hierarchical child code) is 1 when the level has children and 0 when it does not. A subscriber who is also the patient has HL04 = 0 on the 2000B, and the claim sits directly under it.

Patient or subscriber? In 5010, a dependent who can be uniquely identified by the payer, usually through their own member ID, is treated as the subscriber. X12's published interpretation on subscriber versus dependent states this for eligibility and says "the same logic exists in the 837 Claims". So that dependent is reported in 2000B, and the 2000C patient loop is used only when the payer identifies the patient through the subscriber. Payer companion guides can tighten this further.

Interactive Example: 837P Professional Claim

A fictional family practice bills an office visit and a rapid strep test for a patient who is also the subscriber. CLM05 = 11:B:1 is place of service 11 (office), qualifier B, frequency 1 (original claim). The principal diagnosis is in HI with qualifier ABK, and each line is an SV1. The total in CLM02 ($160.00) equals the sum of the lines. This claim's CLM01 is the CLP01 in the 835 guide's sample remittance. All people, providers and IDs are fictional; NPI 1999999992 is a check-digit-valid test value.

Interactive Example: 837I Institutional Claim

A fictional hospital bills an outpatient emergency department visit. CLM05 = 13:A:1 gives the type of bill as facility type 13 with frequency 1 (bill type 131). The claim adds statement dates (DTP*434), institutional codes in CL1, a principal diagnosis and a patient's reason for visit (HI with ABK and APR), an attending provider (NM1*71) and three SV2 lines, each with a revenue code and a procedure code. NPIs 1999999976 and 1999999984 are check-digit-valid test values.

Interactive Example: 837D Dental Claim

A fictional dental group bills a periodic evaluation, an adult prophylaxis and a one-surface posterior resin filling. Dental lines use SV3 with the AD (ADA) qualifier, and the filling adds a TOO segment identifying tooth 30 and the occlusal surface. NPI 1999999968 is a check-digit-valid test value.

837P vs 837I vs 837D

Key Segments Explained

BHT: Beginning of Hierarchical Transaction

BHT*0019*00*EFP20261103A*20261103*1015*CH~

NM1: Submitter, Receiver, Providers, Subscriber, Payer

The 837 uses NM1 for every party. NM101 says which one, and NM108/NM109 carry the identifier.

The billing provider's NPI must pass the NPI check digit, and its address in N3/N4 must be a street address with a nine-digit ZIP code in 5010. The tax ID follows in REF*EI (or REF*SY for an individual's SSN, where allowed).

SBR: Subscriber Information

SBR*P*18*GRP778899******CI~

CLM: Claim Information

CLM*EFP26110301*160***11:B:1*Y*A*Y*Y~

Replacement and void claims also carry the payer's original claim number in REF*F8 in loop 2300. That number comes from CLP07 on the 835.

HI: Health Care Diagnosis and Other Codes

HI*ABK:J029~

HI carries up to 12 codes per segment as composites: a qualifier and a code. ICD-10-CM codes are sent without the decimal point (J029 is J02.9).

837I claims use further HI qualifiers for condition, occurrence, value and procedure codes; the 837I TR3 and the payer's guide list them. In an 837P, SV107 points from each line to the diagnoses in HI by position (1 to 12).

SV1: Professional Service (837P)

SV1*HC:99213*125*UN*1***1~
DTP*472*D8*20261103~

SV2: Institutional Service (837I)

SV2*0450*HC:99284*950*UN*1~

CL1: Institutional Claim Codes (837I)

CL1*1*1*01~

CL101 is the admission type, CL102 the point of origin (admission source) and CL103 the patient status (discharge status). The codes come from the National Uniform Billing Committee's UB-04 code sets. Inpatient claims need this segment; whether a payer also requires it on outpatient claims is set by its companion guide.

SV3 and TOO: Dental Service (837D)

SV3*AD:D2391*140****1~
TOO*JP*30*O~

TOO can repeat (up to 32 times) when a line covers several teeth.

LX and DTP: Service Line Number and Date

Each 2400 loop starts with LX (a line counter starting at 1) and carries the service date in DTP*472, as a single date (D8) or a range (RD8). Many payers also want a line item control number in REF*6R, which the payer returns on the 835 for line-level matching.

837 Validation: What an "EDI 837 Validator" Actually Checks

Claim files are checked in layers. The industry commonly describes them as the WEDI SNIP validation types:

Layers 1 and 2 surface on the 999; claims that pass the file but fail payer edits are rejected on the 277CA. A free X12 parser handles layer 1 and makes layers 2 to 4 readable. Code set and payer rules (layers 5 to 7) need the clearinghouse's or payer's edits, because they depend on licensed code sets, dates of service and contracts.

How the 837 Connects to the 835

See the 835 guide for how the payer reports each adjustment with CAS group codes (CO, PR, OA, PI), CARCs and RARCs.

Common 837 Errors and How to Prevent Them

837 Implementation Checklist

• Get the clearinghouse and payer companion guides for each variant you send
• Confirm GS08/ST03 values for 837P, 837I and 837D
• Confirm payer IDs (NM1*PR) and submitter and receiver IDs with the clearinghouse
• Validate NPIs, tax IDs and the billing provider's street address and nine-digit ZIP
• Decide subscriber versus patient loops using the payer's member ID rules
• Keep CLM01 unique and send REF*6R on lines if you want line-level 835 matching
• Build replacement and void claim workflows using CLM05-3 and REF*F8
• Set up daily review of 999s, 277CAs and 277 status responses
• Reconcile 835 payments back to claims on CLP01
• Test each variant, including a secondary claim with 2320 and 2430 loops if you bill secondary payers

For background on X12 envelopes and acknowledgments, see our EDI document types reference, the 997 functional acknowledgment guide and the 834 enrollment guide for the plan side.

Reading 837 Files With OrderSync's Free Inspector

When a claim file is rejected, the fastest way in is to read it loop by loop. Paste any X12 file into the free EDI inspector to see the envelope, the billing provider, subscriber, claim and service line loops broken out segment by segment, with control-number and segment-count problems flagged. It runs in your browser and needs no signup. Use sample files, or files with patient data removed, when you are trying it out. The EDI to JSON converter and EDI translator work on the same files.

Frequently Asked Questions