Loop Hierarchy

EDI transactions are organized into loops — logical groupings of related segments that repeat together. Understanding loop hierarchy is essential for navigating and interpreting EDI files.

---

What Are Loops?

A loop is a collection of segments that describe a single entity (like a claim, a patient, or a service line) and can repeat multiple times within a transaction.

Key Concepts

Term	Definition
Loop	A named group of segments that belong together
Loop ID	Identifier like 2000A, 2010BA, 2400
Parent Loop	The loop that contains this loop
Child Loop	A loop nested inside another loop
Iteration	One occurrence of a repeating loop
Bounded Loop	Loop with explicit start/end (like LS/LE)

Loop Naming Convention

X12 uses a systematic naming pattern:

1000A, 1000B          — Header/envelope level
2000A, 2000B, 2000C   — Hierarchical levels (Provider, Subscriber, Patient)
2010AA, 2010AB        — Sub-loops of 2000A
2300                  — Claim level
2400                  — Line item level

The letter suffix distinguishes different loops at the same level (A, B, C...).

---

How Loops Appear in EDI Paisan

EDI Paisan presents loop hierarchy in the tree view:

📁 Transaction (ST)
├── 📁 1000A - Submitter
├── 📁 1000B - Receiver
└── 📁 2000A - Billing Provider (HL)
    ├── 📁 2010AA - Billing Provider Name (NM1)
    └── 📁 2000B - Subscriber (HL)
        ├── 📁 2010BA - Subscriber Name (NM1)
        ├── 📁 2010BB - Payer Name (NM1)
        └── 📁 2300 - Claim #1
            ├── 📁 2400 - Line 1
            └── 📁 2400 - Line 2

Tips for navigation:

• Click a loop to expand/collapse its children
• Double-click a segment to see element details
• Use search to find specific loops by ID or content

---

Loop Hierarchy by Transaction Type

837P/837I — Professional/Institutional Claims

The 837 uses hierarchical levels (HL) to organize the billing structure:

Transaction Set (ST/SE)
│
├── Loop 1000A — Submitter Name
│   └── NM1*41 (Submitter)
│
├── Loop 1000B — Receiver Name
│   └── NM1*40 (Receiver)
│
└── Loop 2000A — Billing Provider Hierarchical Level (HL*20)
    │   HL with level code 20
    │
    ├── Loop 2010AA — Billing Provider Name
    │   └── NM1*85 (Billing Provider)
    │
    ├── Loop 2010AB — Pay-To Address (if different from billing)
    │
    └── Loop 2000B — Subscriber Hierarchical Level (HL*22)
        │   HL with level code 22
        │
        ├── Loop 2010BA — Subscriber Name
        │   └── NM1*IL (Insured/Subscriber)
        │
        ├── Loop 2010BB — Payer Name
        │   └── NM1*PR (Payer)
        │
        └── Loop 2000C — Patient Hierarchical Level (HL*23)
            │   Optional — only if patient ≠ subscriber
            │
            ├── Loop 2010CA — Patient Name
            │   └── NM1*QC (Patient)
            │
            └── Loop 2300 — Claim Information (CLM)
                │   One per claim
                │
                ├── Loop 2310A-F — Claim-level Providers
                │   └── Referring, Rendering, Service Facility, etc.
                │
                ├── Loop 2320 — Other Subscriber (COB)
                │   └── Secondary/tertiary payer info
                │
                └── Loop 2400 — Service Line (LX/SV1 or SV2)
                    │   One per service/procedure
                    │
                    └── Loop 2420A-F — Line-level Providers

HL Segment Hierarchy

The HL segment establishes parent-child relationships:

HL*1**20*1~     ← Billing Provider (no parent, has children)
HL*2*1*22*1~   ← Subscriber (parent=1, has children)
HL*3*2*23*0~   ← Patient (parent=2, no children)

Element	Description
HL01	Unique ID within the transaction
HL02	Parent HL ID (empty for top level)
HL03	Level code: 20=Provider, 22=Subscriber, 23=Patient
HL04	Child indicator: 1=has children, 0=no children

---

835 — Remittance Advice

The 835 organizes payment information by claim:

Transaction Set (ST/SE)
│
├── Loop 1000A — Payer Identification
│   └── N1*PR (Payer)
│
├── Loop 1000B — Payee Identification
│   └── N1*PE (Payee/Provider)
│
└── Loop 2000 — Header Number (LX)
    │   Groups related claims/transactions
    │
    └── Loop 2100 — Claim Payment Information (CLP)
        │   One per claim being adjudicated
        │
        ├── CLP — Claim-level payment info
        │
        ├── CAS — Claim-level adjustments
        │   └── Denials, deductibles, coinsurance
        │
        ├── NM1*QC — Patient Name
        │
        ├── NM1*IL — Insured Name (if different)
        │
        ├── NM1*82 — Rendering Provider
        │
        ├── MIA/MOA — Inpatient/Outpatient Adjudication
        │
        └── Loop 2110 — Service Payment Information (SVC)
            │   One per service line
            │
            ├── SVC — Service line payment
            │
            ├── DTM — Service dates
            │
            ├── CAS — Line-level adjustments
            │
            ├── REF — Line item reference numbers
            │
            └── AMT — Line item amounts

Key 835 Loops

Loop	Trigger Segment	Purpose
1000A	N1*PR	Identifies the payer sending the remittance
1000B	N1*PE	Identifies the payee receiving payment
2000	LX	Header grouping (typically one per 835)
2100	CLP	Each claim that was processed
2110	SVC	Each service line within a claim

---

270 — Eligibility Inquiry

The 270 requests eligibility information:

Transaction Set (ST/SE)
│
├── Loop 2000A — Information Source Level (HL*20)
│   │   The payer being queried
│   │
│   └── Loop 2100A — Information Source Name
│       └── NM1*PR (Payer)
│
└── Loop 2000B — Information Receiver Level (HL*21)
    │   The provider making the inquiry
    │
    ├── Loop 2100B — Information Receiver Name
    │   └── NM1*1P (Provider)
    │
    └── Loop 2000C — Subscriber Level (HL*22)
        │
        ├── Loop 2100C — Subscriber Name
        │   └── NM1*IL (Subscriber)
        │
        ├── Loop 2100C — Subscriber Eligibility/Benefit Inquiry
        │   └── EQ (Eligibility/Benefit Inquiry)
        │
        └── Loop 2000D — Dependent Level (HL*23)
            │   Optional — if checking for a dependent
            │
            ├── Loop 2100D — Dependent Name
            │   └── NM1*03 (Dependent)
            │
            └── Loop 2100D — Dependent Eligibility Inquiry
                └── EQ (Eligibility/Benefit Inquiry)

270 HL Codes

HL03 Code	Level	Description
20	Information Source	Payer being queried
21	Information Receiver	Provider making inquiry
22	Subscriber	Member whose eligibility is being checked
23	Dependent	Dependent of subscriber

---

271 — Eligibility Response

The 271 responds to eligibility inquiries:

Transaction Set (ST/SE)
│
├── Loop 2000A — Information Source Level (HL*20)
│   │
│   └── Loop 2100A — Information Source Name
│       └── NM1*PR (Payer)
│
└── Loop 2000B — Information Receiver Level (HL*21)
    │
    ├── Loop 2100B — Information Receiver Name
    │   └── NM1*1P (Provider)
    │
    └── Loop 2000C — Subscriber Level (HL*22)
        │
        ├── Loop 2100C — Subscriber Name
        │   └── NM1*IL (Subscriber)
        │
        ├── Loop 2110C — Subscriber Eligibility/Benefit Info
        │   │   Repeats for each benefit type
        │   │
        │   ├── EB — Eligibility/Benefit Information
        │   │   └── Coverage status, benefit details
        │   │
        │   ├── HSD — Health Care Services Delivery
        │   │   └── Quantity limits, visit limits
        │   │
        │   ├── REF — Reference Numbers
        │   │   └── Prior auth numbers, policy numbers
        │   │
        │   ├── DTP — Date/Time Periods
        │   │   └── Effective dates, term dates
        │   │
        │   ├── MSG — Message Text
        │   │   └── Free-form eligibility notes
        │   │
        │   └── Loop 2115C — Benefit Related Entity
        │       └── NM1 — Related providers/entities
        │
        └── Loop 2000D — Dependent Level (HL*23)
            │
            └── Loop 2110D — Dependent Eligibility/Benefit Info
                └── (Same structure as 2110C)

Common EB (Eligibility/Benefit) Codes

EB01	Meaning
1	Active Coverage
6	Inactive
I	Non-Covered
R	Other/Additional Payor
C	Deductible
A	Co-Insurance
B	Co-Payment
G	Out of Pocket Maximum
F	Limitations

---

Parent-Child Relationships

Understanding Nesting

Loops form a tree structure. Every segment belongs to exactly one loop at any given time:

If you're inside Loop 2300 (Claim):
  ├── Segments here belong to the claim
  │
  └── When you see LX (service line):
        └── Now you're in Loop 2400
            └── Segments here belong to the service line

Loop Boundaries

EDI doesn't have explicit "end loop" markers. A loop ends when:

1. A sibling loop starts — Same-level loop begins (another CLM starts a new claim)
2. A parent loop starts — Higher-level loop begins (new HL subscriber)
3. The transaction ends — SE segment reached

EDI Paisan handles this automatically, presenting a clean tree view without you needing to track boundaries manually.

---

Bounded Loops (LS/LE)

Some transactions use explicit loop boundaries:

LS*2120~           ← Loop start
...segments...
LE*2120~           ← Loop end

This appears in:

• 270/271 for subscriber/dependent benefit loops
• Some payer-specific implementations

EDI Paisan recognizes bounded loops and displays them correctly in the tree view.

---

Tips for Reading Loop Structures

1. Start with the HL Hierarchy

For 837, 270, and 271, the HL segments establish the main structure. Find them first:

# In EDI Paisan, search for: HL*

2. Identify Trigger Segments

Each loop starts with a specific "trigger" segment:

Loop	Trigger	Description
2000A/B/C	HL	Hierarchical level
2010**	NM1	Name segment
2300	CLM	Claim
2400	LX or SV1/SV2	Service line
2100 (835)	CLP	Claim payment
2110 (835)	SVC	Service payment

3. Use the Element Count

When the tree seems wrong, count elements. The SE01 segment contains the total segment count — EDI Paisan validates this and warns about mismatches.

4. Watch for Loop Repeats

A loop like 2400 (service line) repeats for each service. Each iteration contains the same segment types but different data:

LX*1~     ← Service Line 1
SV1*HC:99213*125*UN*1***1~
DTP*472*D8*20240110~

LX*2~     ← Service Line 2
SV1*HC:85025*75*UN*1***1~
DTP*472*D8*20240110~

---

Common Issues

Missing Parent HL

If an HL segment references a non-existent parent:

HL*2*99*22*0~    ← Parent 99 doesn't exist

EDI Paisan will:

• Display a validation warning
• Render the loop at the root level as a fallback

Incorrect Loop Nesting

Some files have segments out of order. EDI Paisan attempts best-effort parsing but may show warnings about structure issues.

Duplicate Loop IDs

Multiple iterations of the same loop (e.g., multiple claims) are normal. They'll appear as siblings in the tree view:

📁 2300 - Claim #1
📁 2300 - Claim #2
📁 2300 - Claim #3

---

Related Documentation

• 837P Professional Claims — Detailed 837P structure
• 835 Remittance Advice — Detailed 835 structure
• 270 Eligibility Inquiry — Detailed 270 structure
• 271 Eligibility Response — Detailed 271 structure
• Segment Reference — All segment types explained