EDI 837P vs 837I: Key Differences Every Biller Should Know

If you work in healthcare billing, you’ve almost certainly dealt with both the 837P and the 837I — even if you didn’t realize there were two distinct formats. Both are HIPAA-compliant X12 EDI transaction sets used to submit healthcare claims electronically. Both share the same transaction set identifier (837). But they serve different billing contexts, follow different loop structures, and contain different required segments.

Confusing the two is a fast path to claim rejections. Knowing exactly how they differ will make you a sharper biller, a better EDI developer, and a faster troubleshooter when something goes wrong.

This post walks through the differences systematically — what each is for, how their structures diverge, and what that looks like in raw X12.

What the P and I Stand For

837P — Professional claims. Used by physicians, outpatient clinics, labs, therapy practices, and other providers who bill using the CMS-1500 paper form as their baseline.
837I — Institutional claims. Used by hospitals, skilled nursing facilities, home health agencies, and other facility-based providers who bill using the UB-04 paper form.

The P and I aren’t just labels — they reflect fundamentally different billing contexts, reimbursement models, and required data elements.

The Core Structural Difference: Claim Level vs. Service Level

Both 837P and 837I use a loop-based structure to organize claim data. The transaction wraps everything in an ISA/GS envelope, then uses a hierarchy of loops to define the submitter, receiver, billing provider, subscriber, patient, and claim details.

The key divergence happens at Loop 2300 (Claim Information) and Loop 2400 (Service Line).

837P: Line-Level Detail

On the 837P, billing is driven at the service line level. Each procedure a provider performs gets its own Loop 2400 entry with:

A CLM segment at the claim level (total charge)
Individual SV1 segments at the line level (per-procedure detail)

This maps to how physician billing works: you billed for an office visit, a lab draw, and an EKG — each line gets its own charge, procedure code, and modifier.

Example — 837P CLM and SV1 segments:

CLM*1234567890*250***11:B:1*Y*A*Y*I~
SV1*HC:99213*125*UN*1***1~
SV1*HC:93000*75*UN*1***2~
SV1*HC:36415*50*UN*1***3~

Breaking this down:

CLM: Claim number 1234567890, total charge $250, place of service 11 (office), relationship B, facility code 1
SV1: Line 1 — HCPCS code 99213, charge $125, unit UN, quantity 1
SV1: Line 2 — HCPCS 93000 (EKG), charge $75
SV1: Line 3 — HCPCS 36415 (venipuncture), charge $50

837I: Revenue Code-Driven Billing

On the 837I, billing is driven by revenue codes at the service line level. The SV2 segment (not SV1) is used, and each line maps to a revenue code category rather than a standalone procedure code.

Example — 837I CLM and SV2 segments:

CLM*9876543210*15000***21:B:1*Y*A*Y*I~
SV2*0120*HC:99223*3500*DA*1~
SV2*0250**800*DA*2~
SV2*0301**450*DA*1~

Breaking this down:

CLM: Claim for inpatient hospital stay, total charge $15,000, place of service 21 (inpatient hospital)
SV2: Revenue code 0120 (room & board), procedure 99223, charge $3,500
SV2: Revenue code 0250 (pharmacy), no specific procedure code, charge $800
SV2: Revenue code 0301 (lab — chemistry), charge $450

Revenue codes are mandatory on 837I and have no equivalent on 837P. That single difference cascades through the entire billing logic.

Loop Differences That Matter

Beyond the claim and service line segments, there are structural loop differences you’ll encounter when parsing or generating these files.

Admission and Discharge Information (837I Only)

Institutional claims require patient admission data that professional claims don’t have. You’ll find this in the CL1 segment inside Loop 2300:

CL1*1*9*01~

Element 1: Admission type code (1 = Emergency)
Element 2: Admission source code (9 = Not Available)
Element 3: Patient status code (01 = Discharged to home)

This segment does not exist in 837P files. If your parser expects it and it’s missing — or vice versa — you’ll get a structural error before a single claim element is even validated.

Attending Physician Loop (2310A) vs. Rendering Provider

On the 837I, Loop 2310A is used for the Attending Physician — typically the physician responsible for the overall inpatient stay.

On the 837P, there’s no concept of an attending physician at the claim loop level. Instead, the Rendering Provider (Loop 2310B) is the key provider loop, representing the individual who performed the service.

Both loops use NM1, PRV, and REF segments, but the qualifier in NM1 differs:

837I Attending: NM1*71*1*JOHNSON*MICHAEL***MD*XX*1234567890~
837P Rendering: NM1*82*1*PATEL*ANJALI***MD*XX*9876543210~

The 71 qualifier = Attending Physician. The 82 qualifier = Rendering Provider. Getting these swapped is a silent error that many clearinghouses won’t catch — but payers will.

Value Codes and Condition Codes (837I Only)

Institutional claims support condition codes (Loop 2300, HI segment with qualifier BG) and value codes (also in HI with qualifier BE). These are facility-specific billing modifiers used to communicate things like:

Condition code 85: Delayed claim (with explanation)
Value code A1: Deductible payer A
Value code D3: Estimated responsibility — patient

Example:

HI*BG:85~
HI*BE:A1:*500.00~

None of these exist on the 837P. Professional billing doesn’t use condition or value codes in X12.

Place of Service vs. Facility Type

This is one of the most common sources of confusion between the two formats.

On the 837P, place of service (POS) codes go inside the CLM segment element 5, component 1:

CLM*1234567890*250***11:B:1*Y*A*Y*I~

Here, 11 is the place of service code (Office). These are standard CMS POS codes.

On the 837I, instead of a POS code, you use a Facility Type Code and a Claim Frequency Code in the same position. The format looks similar but means something completely different:

CLM*9876543210*15000***211:B:1*Y*A*Y*I~

Here, 211 is the facility type/frequency combination:

First two digits (21) = Facility type (inpatient hospital)
Third digit (1) = Claim frequency code (original claim)

This is a critical distinction. Sending a POS code in an 837I where a facility type is expected — or vice versa — will cause immediate claim-level rejections.

Diagnosis Code Placement

Both 837P and 837I use the HI segment for diagnosis codes inside Loop 2300, with ICD-10-CM codes referenced at the claim level. The structure is largely the same:

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

ABK = Principal diagnosis (ICD-10-CM)
ABF = Additional diagnosis

The difference is in how diagnoses link to service lines:

On 837P, each SV1 segment includes a diagnosis code pointer in element 7 that maps back to the HI segment. SV1*HC:99213*125*UN*1***1~ — the trailing 1 points to the first diagnosis.
On 837I, diagnosis codes apply at the claim level. Service lines do not carry individual diagnosis pointers. The entire claim’s diagnosis set governs the bill.

Frequency of Use by Provider Type

Provider Type	Typical Transaction
Physician / Specialist	837P
Outpatient clinic	837P
Independent lab	837P
Ambulance service	837P
Inpatient hospital	837I
Outpatient hospital dept	837I
Skilled nursing facility	837I
Home health agency	837I
Hospice (facility-based)	837I

Some providers submit both. A hospital-employed physician group might send 837P files for professional charges and 837I files for facility charges — two separate billing streams from the same patient encounter.

Common Errors When the Wrong Format Is Used

Sending 837I Segments in an 837P File

The most common mistake: including a CL1 (admission information) segment in a professional claim. Clearinghouses will reject this as a structural error — CL1 isn’t defined in the 837P implementation guide.

Using SV1 in an Institutional File

SV1 is the professional service detail segment. Using it instead of SV2 in an institutional claim will fail loop validation — payers expect SV2 with revenue codes.

Wrong Qualifier in NM1 Loops

Using 82 (Rendering Provider) in an 837I when 71 (Attending Physician) is required — or using 71 in an 837P where it’s not applicable — causes provider loop rejections.

POS vs. Facility Type in CLM

As covered above, this is a silent but critical difference. The field position looks the same; the meaning is completely different. Always validate the CLM05 component against the correct reference.

Quick Reference: 837P vs. 837I at a Glance

Element	837P (Professional)	837I (Institutional)
Paper equivalent	CMS-1500	UB-04
Service line segment	`SV1`	`SV2`
Revenue codes	Not used	Required
Place of service	CMS POS code (CLM05-1)	Facility type code (CLM05-1)
Admission info	Not used	`CL1` segment required
Attending physician loop	Not applicable	Loop 2310A (`NM1*71`)
Diagnosis pointers	Per service line (SV1-7)	Claim level only
Condition/value codes	Not used	`HI` with `BG`/`BE` qualifier
Claim frequency code	Not used	Part of CLM05 component

Takeaways for Billers and EDI Developers

Know which format your system is generating. This sounds obvious, but billing platforms sometimes let configuration errors slip through that result in the wrong format being produced.
Validate against the correct implementation guide. The 837P and 837I each have their own TR3 (Technical Report Type 3) companion guides. WEDI and ASC X12 publish these — use the right one.
Test with real payer sandboxes. Structural errors often don’t surface until submission. Using a payer’s test environment with actual format validation catches issues before they cost you claim rejections.
Watch CLM05 closely. The place of service vs. facility type distinction in CLM05 is the most common silent error when crossing between formats.
Don’t rely on generic EDI validators alone. Generic validators check X12 syntax but not payer-specific business rules. A file can be structurally valid and still get rejected.

Final Thought

The 837P and 837I aren’t just different flavors of the same thing — they reflect two fundamentally different billing models. Understanding that difference at the segment level, not just conceptually, is what separates billers and developers who troubleshoot efficiently from those who chase ghosts.

The raw X12 is always telling you something. You just have to know where to look.

Ready to work with EDI files in your browser? Try EDI Paisan free — no install required.