How to Read an 837I Institutional Claim File (A Visual Guide)

If you work in hospital billing, you’ve dealt with the 837I — even if you’ve never had to open one yourself. Every institutional claim your facility submits to a payer travels as an 837I transaction. Understanding the structure of that file can save hours of troubleshooting, speed up rejection resolution, and give your team more control over the billing process.

This guide breaks down the 837I format in plain terms, with annotated examples, segment-by-segment explanations, and a look at the most common issues that cause claims to fail.

What Is an 837I?

The 837I (officially: ASC X12 Transaction Set 837, Institutional) is the standard electronic format for submitting institutional healthcare claims. It’s the EDI equivalent of the UB-04 paper claim form — the format used by hospitals, skilled nursing facilities, home health agencies, outpatient clinics, and other institutional providers.

The “I” distinguishes it from the 837P (Professional), which maps to the CMS-1500 form and is used by physicians and non-institutional providers.

Key facts:

Governed by the ASC X12 5010 standard (mandated under HIPAA)
Used for: inpatient stays, outpatient visits, emergency services, SNF billing, home health, hospice
Payers — Medicare, Medicaid, commercial insurers — all accept it
Typically generated by your hospital’s HIS or billing system (Epic, Meditech, Cerner, etc.)

If a claim is rejected or denied, one of the first things you need to do is look at the raw 837I file. That’s what this guide prepares you for.

The Big Picture: How an 837I File Is Structured

An 837I file is a flat text file made up of segments. Each segment starts with a two- or three-character identifier, followed by data elements separated by *, and ends with ~.

The file is organized into nested loops — groups of segments that describe a specific entity (like an insurer, a patient, or a claim). Think of it like a set of labeled envelopes inside other envelopes.

Here’s the hierarchy at a glance:

ISA  — Interchange Control Header
  GS  — Functional Group Header
    ST  — Transaction Set Header
      BHT — Beginning of Hierarchical Transaction
        Loop 1000A — Submitter
        Loop 1000B — Receiver
        Loop 2000A — Billing Provider Hierarchical Level
          Loop 2010AA — Billing Provider Name
          Loop 2000B — Subscriber Hierarchical Level
            Loop 2010BA — Subscriber Name
            Loop 2010BB — Payer Name
            Loop 2300  — Claim Information
              Loop 2400  — Service Line (Institutional)
    SE  — Transaction Set Trailer
  GE  — Functional Group Trailer
IEA — Interchange Control Trailer

Each level adds more specificity. The claim itself lives in Loop 2300. The service lines live in Loop 2400.

Segment-by-Segment Breakdown

Let’s walk through a real 837I snippet and explain each piece.

Interchange and Group Envelope (ISA / GS)

ISA*00*          *00*          *ZZ*SUBMITTERID    *ZZ*PAYERID        *260315*1430*^*00501*000000001*0*P*:~
GS*HC*SUBMITTERID*PAYERID*20260315*1430*1*X*005010X223A2~

Segment	What It Means
`ISA`	Opens the interchange envelope. Contains sender/receiver IDs, date/time, version, and the ISA control number.
`ISA06`	Submitter ID (your facility or clearinghouse)
`ISA08`	Receiver/Payer ID
`ISA15`	`P` = Production, `T` = Test — this matters; test claims sent to production cause rejections
`GS`	Opens the functional group. `GS01 = HC` = Health Care Claim
`GS08`	Implementation guide version — `005010X223A2` is the 837I guide

What to check: Mismatched ISA IDs, wrong P/T flag, and invalid version strings are all common interchange-level rejections.

Transaction Set Header (ST / BHT)

ST*837*0001*005010X223A2~
BHT*0019*00*BATCHID001*20260315*1430*CH~

Segment	What It Means
`ST*837`	Starts the transaction. `0001` is the transaction set control number.
`BHT`	Beginning of the transaction. `BHT03` is your internal batch/control ID. `BHT06 = CH` means claims (vs. `RP` = reporting).

Billing Provider (Loop 2010AA)

NM1*85*2*GENERAL HOSPITAL*****XX*1234567890~
N3*123 MAIN STREET~
N4*ANYTOWN*NY*10001~

Segment	What It Means
`NM1*85`	Billing Provider name. `NM102 = 2` = organization (not individual)
`NM109`	NPI — the provider’s National Provider Identifier
`N3`	Street address
`N4`	City, state, ZIP

What to check: The NPI in NM109 must match what’s on file with the payer. A single digit off = rejection.

Subscriber / Patient (Loop 2010BA / 2010CA)

NM1*IL*1*DOE*JANE****MI*XYZ123456789~
DMG*D8*19650401*F~

Segment	What It Means
`NM1*IL`	Subscriber (insured). `IL` = Insured or Subscriber
`NM109`	Member ID / Insurance ID
`DMG`	Demographic: date of birth (`D8` format = CCYYMMDD) and gender

If the patient is different from the subscriber, a Loop 2010CA follows with the patient’s own NM1.

Claim Information (Loop 2300) — The Heart of the 837I

CLM*CLAIM12345*8500.00***11:B:1*Y*A*Y*I~
DTP*435*D8*20260310~
DTP*096*D8*20260312~
CL1*1*9*01~
HI*ABK:J18.9~
HI*BK:J96.00*BK:I10~

This is where the core claim data lives.

Segment	Element	What It Means
`CLM`	`CLM01`	Your claim/patient account number
`CLM`	`CLM02`	Total billed amount
`CLM`	`CLM05`	Composite element tied to the UB-04 Type of Bill (TOB). The three components together are: (1) Type of Facility, (2) Type of Care, (3) Claim Frequency. In the example `11:B:1`: facility type = `11` (hospital), care type = `B` (varies by context in the implementation guide), claim frequency = `1` (original). These are not independent “facility type,” “claim frequency,” and “bill type” fields — they are three sub-elements of a single composite that mirrors the TOB on the UB-04.
`DTP*435`		Admission date
`DTP*096`		Discharge date
`CL1`	`CL101`	Admission type code (`1` = Emergency)
`CL1`	`CL102`	Admission source code (`9` = not available)
`CL1`	`CL103`	Patient status at discharge (`01` = discharged home)
`HI*ABK`		Principal diagnosis code (ICD-10-CM). `ABK` = ICD-10 principal
`HI*BK`		Additional/secondary diagnoses

The HI segment is critical. Wrong diagnosis qualifiers, invalid ICD-10 codes, or missing codes are among the top causes of claim-level rejections.

Quick reference for common HI qualifier codes:

Qualifier	Meaning
`ABK`	ICD-10-CM Principal Diagnosis
`BK`	ICD-10-CM Other Diagnoses
`BR`	ICD-10-PCS Principal Procedure
`BBR`	ICD-10-PCS Other Procedures
`DR`	DRG Code

Service Lines (Loop 2400 — SV2)

The 837I uses SV2 for service lines (not SV1 like the 837P — this is a key difference).

LX*1~
SV2*0450*HC:99285*1200.00*UN*1***1~
DTP*472*D8*20260310~

Segment	Element	What It Means
`LX`		Line counter (sequential)
`SV2*0450`	`SV201`	Revenue code (`0450` = Emergency Room)
`SV2`	`SV202`	Procedure code (HCPCS/CPT). Format: `HC:` prefix + code
`SV2`	`SV203`	Line-level billed amount
`SV2`	`SV204`	Unit of measure (`UN` = units)
`SV2`	`SV205`	Units/quantity
`SV2`	`SV207`	Diagnosis code pointer(s) — links to HI segment
`DTP*472`		Date of service

Institutional service lines almost always require a revenue code, and most payers will reject claims that omit one. This is the biggest structural difference from the 837P. Revenue codes are required for institutional billing; professional claims don’t use them. Some payer companion guides define situational exceptions, but in practice omitting a revenue code will trigger validation failures at most clearinghouses.

Institutional-Only Concepts That Distinguish the 837I

If you’re familiar with the 837P (professional claims), the 837I introduces several concepts that have no equivalent on the CMS-1500 side. These are the elements that immediately identify a transaction as institutional — and the ones most likely to trip up anyone new to hospital billing EDI.

1. Type of Bill (TOB)

Encoded in the CLM05 composite, the TOB is a three-component code identifying the facility type, type of care, and claim frequency. It is foundational to institutional claims and has no direct parallel in the 837P. Payers use it to route claims to the correct adjudication rules.

2. Revenue Codes

Reported in SV201 on every service line. Revenue codes classify the type of service or accommodation being billed — for example, 0120 = room and board (semi-private), 0450 = emergency room, 0250 = pharmacy. There is no equivalent in the 837P; professional claims use procedure codes without a revenue code layer.

3. Condition Codes

Reported in HI segments using qualifier BG. Condition codes indicate special circumstances that affect claim processing — for example, Medicare secondary payer situations, disaster-related care, or specific billing scenarios required by CMS or state Medicaid. A missing or incorrect condition code can cause claim suspension or denial even when the clinical data is correct.

4. Occurrence Codes

Also reported in HI segments. Occurrence codes capture significant events related to the claim — accident dates, insurance-related events, start of disability, etc. Each occurrence code is paired with a date. They originate from the UB-04 form fields and carry forward into the 837I.

5. Occurrence Span Codes

Similar to occurrence codes but cover date ranges rather than single dates. Used for things like leave-of-absence periods, quality improvement organization review periods, or other spans of time relevant to the claim. Reported in HI segments with a start and end date.

6. Value Codes

Reported in HI segments with qualifier BE. Value codes carry monetary or numeric amounts tied to specific claim circumstances — covered days, Medicare coinsurance amounts, payer-specific dollar figures required for coordination of benefits, and more. Missing value codes are a common source of Medicare and Medicaid rejections.

Quick identification tip: When an analyst needs to determine whether an unknown X12 claim file is 837I or 837P, the presence of revenue codes in SV2 segments, occurrence/condition codes in HI segments, and a TOB value in CLM05 are the fastest tells. If you see SV2 instead of SV1, it’s institutional.

Full Sample Snippet (Annotated)

Note: This sample has been shortened for readability and is not intended as a fully compliant production claim. Many situational segments have been omitted, and some payer companion guides may impose additional requirements.

Here’s a simplified but representative 837I for an inpatient stay:

ISA*00*          *00*          *ZZ*MYHOSPITAL     *ZZ*BCBSPAYER      *260315*0900*^*00501*000000100*0*P*:~
GS*HC*MYHOSPITAL*BCBSPAYER*20260315*0900*100*X*005010X223A2~
ST*837*0001*005010X223A2~
BHT*0019*00*BATCH001*20260315*0900*CH~
  [Loop 1000A - Submitter]
NM1*41*2*MY HOSPITAL SYSTEM*****46*MYSUBMITTERID~
  [Loop 1000B - Receiver]
NM1*40*2*BCBS PAYER*****46*BCBSPAYERID~
  [Loop 2000A - Billing Provider HL]
HL*1**20*1~
PRV*BI*PXC*282N00000X~
  [Loop 2010AA - Billing Provider]
NM1*85*2*MY HOSPITAL*****XX*1112223334~
N3*456 HEALTH BLVD~
N4*METROPOLIS*NY*10002~
  [Loop 2000B - Subscriber HL]
HL*2*1*22*0~
SBR*P*18*******MB~
  [Loop 2010BA - Subscriber]
NM1*IL*1*SMITH*ROBERT****MI*1EG4-TE5-MK72~
N3*789 OAK AVE~
N4*SPRINGFIELD*IL*62701~
DMG*D8*19480822*M~
  [Loop 2010BB - Payer]
NM1*PR*2*BCBS OF ILLINOIS*****PI*00630~
  [Loop 2300 - Claim]
CLM*ACCT20260001*45000.00***11:B:1*Y*A*Y*I~
DTP*435*D8*20260301~
DTP*096*D8*20260308~
CL1*1*1*30~
HI*ABK:I21.9~
HI*BK:I10*BK:E11.9~
HI*BR:02HW3ZZ~
  [Loop 2400 - Service Line 1]
LX*1~
SV2*0120*HC:99238*1200.00*UN*1***1~
DTP*472*RD8*20260301-20260308~
  [Loop 2400 - Service Line 2]
LX*2~
SV2*0250*HC:J7040*850.00*UN*3***1~
DTP*472*RD8*20260301-20260308~
SE*42*0001~
GE*1*100~
IEA*1*000000100~

Reading this claim: Robert Smith was admitted 3/1/2026, discharged 3/8/2026 with a principal dx of acute MI (I21.9) and secondary diagnoses of hypertension (I10) and type 2 diabetes (E11.9). Two revenue/service lines are billed: room and board (0120) and pharmacy (0250). Total billed: $45,000.

Common Mistakes and What to Look For

These are the issues that show up most in 837I rejections and denials:

1. Wrong Claim Frequency Code (`CLM05-3`)

1 = Original claim
7 = Replacement claim
8 = Void/cancel

Sending a 1 when you meant 7 for a resubmission is a fast way to get a duplicate claim rejection.

Clarification: CLM05-3 (the third component of the CLM05 composite) is the claim frequency code. The B value that sometimes appears in CLM05-2 refers to the Type of Care sub-element — a completely different field. These two positions are unrelated; only CLM05-3 controls whether a claim is original, replacement, or void.

2. Mismatched or Invalid NPI (`NM109`)

The billing provider NPI must match the payer’s enrollment records. Type 2 NPIs are for organizations; Type 1 are for individuals. Using the wrong type causes claim-level rejections.

3. Missing Revenue Codes (`SV201`)

Every service line in an 837I must have a revenue code. If your billing system generates a line without one, it will fail HIPAA compliance validation before it ever reaches the payer.

4. ICD-10 Qualifier Errors (`HI`)

Using the wrong qualifier prefix (ABK vs BK, or BR vs BBR) on diagnosis/procedure codes causes payers to misread the claim. Always verify your system is populating qualifier codes correctly.

5. Date Format Issues (`DTP`)

Dates must follow D8 format (CCYYMMDD). Date ranges use RD8 with a hyphen separator (e.g., 20260301-20260308). Wrong format = rejection.

6. Admission Type and Source Codes (`CL1`)

These populate from registration data. Blank or incorrect codes affect DRG assignment and can trigger clinical audits or claim suspensions.

7. Diagnosis Pointer Mismatch (`SV207`)

Service lines link to diagnoses via pointer numbers. If your file has 4 diagnoses but a line points to position 5, the claim will error.

837I context note: Diagnosis pointers (SV207) are technically present in the 837I, but they are far more commonly the primary rejection cause in 837P (professional) billing than in institutional billing. For 837I users, the heavier focus should be on revenue codes, occurrence codes, condition codes, and proper HI segment coding — these are the elements that drive most institutional-specific rejections. Diagnosis pointer mismatches do occur in 837I, but they are less frequently the root cause compared to professional claims.

How edipaisan.com Can Help

Reading an 837I manually is tedious. The file is dense, the segment order matters, and a single character in the wrong place can mean a rejected claim and delayed payment.

edipaisan.com gives you a visual, human-readable breakdown of your 837I files — without needing to know X12 syntax by heart.

Upload your 837I file and get a structured, segment-by-segment view
Spot errors and mismatches instantly
Validate claim data before submission
Works for 837I, 837P, 835, 270/271, and more

If your team is dealing with unexplained rejections, resubmission delays, or just wants more visibility into the claims your system is generating — give it a try.

Try it free at edipaisan.com →

Wrapping Up

The 837I is the backbone of institutional claim submission. Once you understand the loop and segment structure — ISA to IEA, HLs to CLM to SV2 — you can move from “why was this rejected?” to “I see exactly what happened” in minutes instead of hours.

Key takeaways:

837I maps to the UB-04; it’s used by hospitals, SNFs, home health, and other institutional providers
The file nests loops hierarchically: interchange → group → transaction → claim → service line
CLM, HI, and SV2 carry the most claim-critical data
Revenue codes (SV201) are required on almost all institutional service lines — most payers will reject claims that omit them
Most rejections trace back to a handful of recurring issues: NPI mismatches, wrong qualifiers, date format errors

Understanding the file your billing system produces — not just the abstract form behind it — is one of the most practical skills a hospital billing team can develop.

Have questions about a specific segment or rejection code? Contact us or explore the edipaisan.com blog for more EDI guides.