Reference·X12 837I·SBR
X12 837I Reference

X12 837I SBR Segment Guide: Fields, Format, and Testing Gotchas

Jul 28, 2026 · 6 min read

SBR does the same coordination-of-benefits job on a hospital claim that it does on a physician claim — it tells a payer whether it's being billed first, second, or third for this stay — but institutional billing teams juggle secondary and tertiary payers on inpatient claims constantly, so an SBR mistake here shows up in test failures far more often than it does on the professional side.

Quick answer

SBR (Subscriber Information) is a repeatable segment on an X12 837I claim, one occurrence per payer involved, that establishes each payer's payment sequence, the patient's relationship to the subscriber, and the type of payer being billed for that occurrence.

The elements that actually matter in practice

SBR01 →
Payer Responsibility Sequence Number Code — P/S/T — primary, secondary, or tertiary payer for this claim — see the dedicated page below
SBR02 →
Individual Relationship Code — how the patient relates to the subscriber — self, spouse, child, etc. — see the dedicated page below
SBR03
Reference Identification — the group or policy number tied to this coverage
SBR09 →
Claim Filing Indicator Code — the category of payer being billed — commercial, Medicare, Medicaid, and others — see the dedicated page below

Example

Synthetic example Generated by Synthibase
SBR*S*01*GRP-77410*RIVERBEND HEALTH PLAN*****MB*

SBR01 = S marks this payer as secondary, SBR02 = 01 marks the patient as the spouse of the subscriber, and SBR09 = MB marks the plan as Medicare Part B. Synthetic claim data.

Where this trips people up

Inpatient stays routinely involve Medicare as primary and a supplemental or Medicaid plan as secondary, and teams building institutional test data often hardcode SBR09 to whatever filing code the happy-path claim used rather than varying it per payer occurrence. The claim validates fine, but a secondary Medicaid loop tagged with a commercial filing indicator gets adjudicated against the wrong benefit rules, and that failure only surfaces once the remit comes back — long after the claim itself looked clean in testing.

How to Test 837I Institutional Claims: A Complete Guide
How to Write EDI Test Cases That Actually Catch Go-Live Failures
Generate synthetic institutional COB scenarios automatically
Synthibase generates synthetic 837I claims with correctly sequenced SBR loops across Medicare, Medicaid, and commercial payers — no PHI, no sequence mistakes.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.