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

Stop squinting at raw EDI. Here’s how to actually understand what’s inside an 837P professional claim file.

If you’ve ever opened an 837P file in a text editor, you know the feeling: a solid wall of cryptic codes, tildes, asterisks, and colons with no line breaks in sight. It looks like someone smashed their keyboard and called it healthcare data.

But here’s the thing — once you understand the structure, 837P files are surprisingly logical. This guide will walk you through the anatomy of an 837P professional claim file, explain what each section means, and show you a better way to work with them.

What Is an 837P File?

An 837P (Professional) is a HIPAA X12 electronic transaction used to submit healthcare claims from providers to payers (insurance companies). It’s the digital version of the old CMS-1500 paper claim form.

Every time a doctor’s office, therapist, or outpatient facility bills insurance electronically, an 837P is involved. If you work in medical billing, revenue cycle management, or healthcare IT, these files are part of your daily life.

Related file types:

837I — Institutional claims (hospitals, skilled nursing facilities)
835 — Remittance advice (payment explanations from payers)
270/271 — Eligibility inquiries and responses

The Raw Reality

Here’s what a typical 837P looks like when you open it in Notepad:

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *230615*1245*^*00501*000000001*0*P*:~GS*HC*SENDER*RECEIVER*20230615*1245*1*X*005010X222A1~ST*837*0001*005010X222A1~BHT*0019*00*12345*20230615*1245*CH~NM1*41*2*ABC BILLING SERVICE*****46*123456789~PER*IC*JANE DOE*TE*5551234567~NM1*40*2*BLUE CROSS*****46*987654321~HL*1**20*1~NM1*85*2*SMITH FAMILY MEDICINE*****XX*1234567890~N3*123 MAIN STREET~N4*ANYTOWN*MA*02101~REF*EI*111222333~HL*2*1*22*0~SBR*P*18*******CI~NM1*IL*1*JOHNSON*ROBERT****MI*ABC123456~N3*456 ELM STREET~N4*PLYMOUTH*MA*02360~DMG*D8*19800115*M~NM1*PR*2*BLUE CROSS BLUE SHIELD*****PI*12345~CLM*PAT001*150***11:B:1*Y*A*Y*Y~DTP*431*D8*20230610~LX*1~SV1*HC:99213*75*UN*1***1~DTP*472*D8*20230610~LX*2~SV1*HC:99395*75*UN*1***1~DTP*472*D8*20230610~SE*25*0001~GE*1*1~IEA*1*000000001~

Yeah. That’s what billing teams are expected to work with.

Let’s break it down.

The Structure: Envelopes Inside Envelopes

Think of an 837P like a set of Russian nesting dolls. There are layers, and each layer wraps the one inside it:

Layer 1: The Interchange Envelope (ISA/IEA)

The outermost wrapper. Think of it as the shipping container.

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *230615*1245*^*00501*000000001*0*P*:~
...
IEA*1*000000001~

What it tells you:

Who sent it (ISA06: SENDER)
Who it’s going to (ISA08: RECEIVER)
Date and time (ISA09/ISA10: June 15, 2023 at 12:45)
Control number (ISA13: 000000001) — this must match the IEA
Production or test (ISA15: P = Production, T = Test)

The ISA segment is always exactly 106 characters. Always. It’s the one thing in EDI you can count on.

Layer 2: The Functional Group (GS/GE)

Inside the interchange, one or more functional groups specify the transaction type.

GS*HC*SENDER*RECEIVER*20230615*1245*1*X*005010X222A1~
...
GE*1*1~

Key fields:

GS01: HC — Health Care claim (this is how you know it’s an 837)
GS08: 005010X222A1 — The implementation guide version (5010 is the current HIPAA standard)

Layer 3: The Transaction Set (ST/SE)

This is where the actual claim data lives.

ST*837*0001*005010X222A1~
BHT*0019*00*12345*20230615*1245*CH~
...
SE*25*0001~

The BHT (Beginning of Hierarchical Transaction) tells you:

BHT02: 00 — Original transmission (not a replacement or void)
BHT06: CH — Chargeable (this is a real claim, not a query)

Layer 4: The Hierarchical Levels (HL Loops)

This is where people get lost. The HL segments create a hierarchy:

HL*1**20*1 — Level 20 = Billing Provider (the entity submitting the claim)
HL*2*1*22*0 — Level 22 = Subscriber (the insured patient), child of HL 1

Under the billing provider you’ll find:

NM1*85 — Billing provider name and NPI
N3/N4 — Address
REF*EI — Tax ID (EIN)

Under the subscriber:

NM1*IL — Subscriber (insured) name and member ID
DMG — Demographics (date of birth, gender)
NM1*PR — Payer name and ID

Layer 5: The Claim (CLM Segment)

The CLM segment is the heart of the file. Each CLM represents one claim.

CLM*PAT001*150***11:B:1*Y*A*Y*Y~

Breaking it down:

CLM01: PAT001 — Patient account number
CLM02: 150 — Total charge amount ($150.00)
CLM05: 11:B:1 — Place of service (11 = Office), frequency (1 = Original)

Layer 6: Service Lines (LX/SV1)

Under each claim, individual service lines detail what was done:

LX*1~
SV1*HC:99213*75*UN*1***1~
DTP*472*D8*20230610~

Translation:

CPT code 99213 — Office visit, established patient, moderate complexity
$75.00 charge
1 unit of service
Date of service: June 10, 2023

LX*2~
SV1*HC:99395*75*UN*1***1~
DTP*472*D8*20230610~

CPT code 99395 — Preventive visit, established patient, 18-39 years
$75.00 charge

Two service lines, $75 each = $150 total (matching the CLM02 amount).

Common 837P Segments at a Glance

Segment	Name	What It Contains
ISA/IEA	Interchange envelope	Sender, receiver, control numbers
GS/GE	Functional group	Transaction type, version
ST/SE	Transaction set	Claim transaction wrapper
BHT	Beginning of transaction	Purpose, type, reference
NM1	Name	Entity names (billing provider, patient, payer)
N3/N4	Address	Street, city, state, zip
REF	Reference	IDs (tax ID, NPI, etc.)
HL	Hierarchical level	Nesting structure
SBR	Subscriber	Insurance info, relationship
CLM	Claim	Account number, charges, place of service
DTP	Date/Time	Service dates, admission dates
LX	Service line counter	Line number
SV1	Service line (professional)	CPT code, charge, units
DMG	Demographics	DOB, gender

Why This Matters

Understanding 837P structure isn’t just academic — it’s practical:

Claim rejections often come down to a bad segment value (wrong qualifier, missing NPI, mismatched control numbers). If you can read the file, you can find the problem.
File splitting — when you need to extract one claim from a batch of 5,000, knowing the HL/CLM hierarchy tells you exactly where to cut.
Troubleshooting with clearinghouses and payers goes much faster when you can point to the exact segment causing issues.

There’s a Better Way

You don’t have to read raw EDI. Tools exist that can parse these files into something human-friendly.

EDI Paisan is a free, browser-based viewer built specifically for healthcare EDI files. Drop in an 837P and instantly see:

Tree View — the hierarchical structure laid out as a navigable tree, just like the nesting dolls we described above
Grid View — claim data in familiar rows and columns
Raw View — the original EDI with proper formatting and segment highlighting

Plus validation that catches envelope errors, control number mismatches, and segment count issues before you submit to a clearinghouse.

No installation. No account required for viewing. Files up to 100MB.

Try it free at edipaisan.com →

EDI Paisan is built by healthcare IT engineers who got tired of explaining EDI files in Notepad. We build modern tools for the people who keep healthcare running.