HIPAA X12 EDI File Structure: A Complete Overview
If you work in healthcare billing, revenue cycle management, or EDI development, you’ve almost certainly opened an X12 file and wondered exactly how all those cryptic characters fit together. The structure isn’t arbitrary — it follows a precise HIPAA-mandated schema that, once you understand it, makes every file you touch much easier to read, validate, and troubleshoot.
This guide breaks down the full HIPAA X12 EDI file structure, from the outermost envelope to individual data elements, with real X12 examples throughout.
What Is HIPAA X12 EDI?
Electronic Data Interchange (EDI) is the computer-to-computer exchange of standard business documents. In healthcare, HIPAA mandates the use of X12 transaction standards developed by the Accredited Standards Committee (ASC X12) for nearly every administrative and financial exchange — eligibility checks, claims submissions, claim status inquiries, remittance advice, and more.
The key HIPAA-mandated transaction sets include:
| Transaction Set | Purpose |
|---|---|
| 270 / 271 | Eligibility inquiry / response |
| 276 / 277 | Claim status inquiry / response |
| 278 | Prior authorization |
| 835 | Electronic remittance advice (ERA) |
| 837P | Professional claim |
| 837I | Institutional claim |
| 837D | Dental claim |
| 834 | Benefit enrollment |
| 820 | Premium payment |
All of these share the same X12 envelope structure at the outermost layers. Understanding that structure is the foundation of all EDI work.
The Three-Layer Envelope System
Think of an X12 file like a set of Russian nesting dolls. There are three concentric envelopes, each opened and closed by a matching pair of segments:
ISA ... IEA ← Interchange Envelope (outermost)
GS ... GE ← Functional Group Envelope
ST ... SE ← Transaction Set Envelope (innermost)Each layer controls a different scope — interchange controls the connection between two trading partners, functional groups organize related transactions, and transaction sets contain the actual business documents.
Let’s go layer by layer.
Layer 1: The Interchange Envelope (ISA / IEA)
The ISA (Interchange Control Header) is literally the first segment of every X12 file. It identifies the sender and receiver at the interchange level and sets the delimiter characters used throughout the file.
ISA*00* *00* *ZZ*SENDER_ID *ZZ*RECEIVER_ID *261102*1800*^*00501*000000001*0*P*:~Breaking down each ISA element:
| Position | Element | Value | Meaning |
|---|---|---|---|
| ISA01 | Auth Info Qualifier | 00 | No authorization |
| ISA02 | Auth Info | (spaces) | Filler (10 chars) |
| ISA03 | Security Qualifier | 00 | No security |
| ISA04 | Security Info | (spaces) | Filler (10 chars) |
| ISA05 | Sender ID Qualifier | ZZ | Mutually defined |
| ISA06 | Interchange Sender ID | SENDER_ID | 15-char padded sender |
| ISA07 | Receiver ID Qualifier | ZZ | Mutually defined |
| ISA08 | Interchange Receiver ID | RECEIVER_ID | 15-char padded receiver |
| ISA09 | Date | 261102 | YYMMDD |
| ISA10 | Time | 1800 | HHMM |
| ISA11 | Repetition Separator | ^ | Used within elements |
| ISA12 | Version | 00501 | X12 version 5010 |
| ISA13 | Interchange Control # | 000000001 | Unique control number |
| ISA14 | Ack Requested | 0 | No TA1 requested |
| ISA15 | Usage Indicator | P | P=Production, T=Test |
| ISA16 | Component Separator | : | Sub-element delimiter |
The final character in the ISA segment (after :~) is the segment terminator — in this case ~. The * between elements and the ~ at the end of each segment are the two delimiters you’ll see throughout every X12 file.
The matching IEA (Interchange Control Trailer) closes this envelope:
IEA*1*000000001~IEA01= number of functional groups includedIEA02= must match ISA13 control number exactly
Validation tip: A mismatch between ISA13 and IEA02 is one of the most common interchange-level rejections. Always verify control numbers match.
Layer 2: The Functional Group Envelope (GS / GE)
Inside each interchange, you can have one or more functional groups. A functional group bundles together transaction sets of the same type — for example, all 837P claims going to a single payer.
GS*HC*SENDER_APP*RECEIVER_APP*20261102*1800*1*X*005010X222A2~| Element | Value | Meaning |
|---|---|---|
| GS01 | HC | Functional ID — HC = Health Care Claim |
| GS02 | SENDER_APP | Application sender code |
| GS03 | RECEIVER_APP | Application receiver code |
| GS04 | 20261102 | Date (CCYYMMDD format) |
| GS05 | 1800 | Time (HHMM) |
| GS06 | 1 | Group control number |
| GS07 | X | Responsible agency (X12) |
| GS08 | 005010X222A2 | Version/release — this is the HIPAA Implementation Guide identifier |
The GS08 version string is critical — it tells your translator exactly which HIPAA implementation guide applies to the transactions inside. Common values:
| GS08 Value | Transaction |
|---|---|
| 005010X279A1 | 270/271 Eligibility |
| 005010X212 | 276/277 Claim Status |
| 005010X217 | 278 Prior Auth |
| 005010X221A1 | 835 Remittance |
| 005010X222A2 | 837P Professional |
| 005010X223A3 | 837I Institutional |
| 005010X224A3 | 837D Dental |
Closing the group:
GE*1*1~GE01= number of transaction sets in this groupGE02= must match GS06
Layer 3: The Transaction Set Envelope (ST / SE)
The ST (Transaction Set Header) and SE (Transaction Set Trailer) wrap the actual business document — one claim, one remittance file, one eligibility response.
ST*837*0001*005010X222A2~ST01= transaction set identifier (837, 835, 270, etc.)ST02= unique transaction set control number (0001–9999)ST03= implementation convention reference (same as GS08)
Closing:
SE*42*0001~SE01= total segment count, including ST and SE themselvesSE02= must match ST02
Validation tip: SE01 must exactly equal the number of segments from ST to SE inclusive. Miscounts here are an extremely common source of structural rejections.
Inside the Transaction Set: Loops and Segments
Within the ST/SE envelope is where the real data lives, organized into loops — repeating groups of related segments.
Segments
A segment is a single line of an X12 file, terminated by the segment terminator (~). Each segment starts with a segment ID (2–3 characters), followed by data elements separated by the element delimiter (*).
Example from an 837P claim:
CLM*123456789*250***11:B:1*Y*A*Y*I~CLM= Claim Information segmentCLM01= Patient Control Number (123456789)CLM02= Monetary Amount (250— total claim charge)CLM05-1= Place of Service Code (11= Office)CLM05-2= Facility Code Qualifier (B)CLM05-3= Claim Frequency Type Code (1= Original)CLM06= Provider Signature on File (Y)CLM07= Medicare Assignment Code (A)CLM08= Benefits Assignment Cert Indicator (Y)CLM09= Release of Information Code (I)
Loops
Loops group related segments that repeat together. For example, in an 837P file, the Loop 2000B contains subscriber information and can repeat once per subscriber, while Loop 2300 contains claim information and repeats once per claim.
A simplified 837P structure looks like this:
ST*837*0001*005010X222A2~
BPR...~ ← (in 835; in 837, BHT opens the file header)
BHT*0019*00*BATCHID*20261102*1800*CH~
[Loop 1000A — Submitter]
NM1*41*2*BILLING COMPANY*****46*123456789~
PER*IC*EDI CONTACT*TE*8005551234~
[Loop 1000B — Receiver]
NM1*40*2*PAYER NAME*****46*PAYERID~
[Loop 2000A — Billing Provider]
HL*1**20*1~
PRV*BI*PXC*207Q00000X~
NM1*85*2*PROVIDER NAME*****XX*1234567890~
N3*123 MAIN ST~
N4*ANYTOWN*MA*02360~
[Loop 2000B — Subscriber]
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*DOE*JANE****MI*ABC123456789~
DMG*D8*19800101*F~
[Loop 2300 — Claim]
CLM*123456789*250***11:B:1*Y*A*Y*I~
DTP*431*D8*20261028~
REF*D9*CLAIMNUMBER~
HI*ABK:Z23.0~
[Loop 2400 — Service Line]
LX*1~
SV1*HC:99213*150*UN*1***1~
DTP*472*D8*20261028~
[Loop 2400 — Service Line 2]
LX*2~
SV1*HC:93000*100*UN*1***1~
DTP*472*D8*20261028~
SE*42*0001~
GE*1*1~
IEA*1*000000001~Key Segments You’ll Encounter Constantly
NM1 — Individual or Organizational Name
The NM1 segment appears dozens of times in most HIPAA transactions. It identifies any named entity — patient, provider, payer, employer.
NM1*IL*1*DOE*JOHN*A***MI*XYZ987654321~NM101= Entity Identifier Code (IL= Insured or Subscriber)NM102= Entity Type Qualifier (1= Person,2= Non-Person)NM103= Last/Org NameNM104= First NameNM105= Middle NameNM108= ID Code Qualifier (MI= Member ID)NM109= ID Code (actual member ID)
DTP — Date/Time Reference
DTP*472*D8*20261028~DTP01= Date/Time Qualifier (472= Service Date)DTP02= Date Format Qualifier (D8= CCYYMMDD)DTP03= Date Value
REF — Reference Identification
REF*1K*AUTH12345~REF01= Reference Identification Qualifier (1K= Prior Authorization)REF02= Reference ID value
Hierarchical Levels (HL Segments)
One of the more complex structural elements in 837 files is the HL (Hierarchical Level) segment. HL segments establish a parent-child relationship between loops — billing provider → subscriber → patient → claim.
HL*1**20*1~ ← Billing Provider (level 1, no parent, has children)
HL*2*1*22*0~ ← Subscriber (level 2, parent=1, no children beyond this loop)HL01= Hierarchical ID (sequential counter)HL02= Parent Hierarchical ID (blank for root)HL03= Hierarchical Level Code (20=Billing Provider,22=Subscriber,23=Patient)HL04= Hierarchical Child Code (1=has children,0=no children)
Mismatched or incorrect HL values are a frequent structural error that causes full-file rejections.
Common Structural Validation Errors
Understanding the structure helps you catch errors before submission:
| Error | Root Cause |
|---|---|
| ISA/IEA control number mismatch | ISA13 ≠ IEA02 |
| GS/GE count mismatch | GE01 ≠ actual transaction set count |
| ST/SE segment count off | SE01 includes or excludes ST/SE itself |
| HL parent reference missing | HL02 references nonexistent HL01 |
| Missing required segment | Implementation Guide requires segment not present |
| Invalid qualifier value | Element value not in X12 code table |
| Delimiter collision | Data contains *, ~, or : unescaped |
Most EDI clearinghouses will return a 999 Implementation Acknowledgment (or a 997 Functional Acknowledgment for older versions) indicating whether each transaction set was accepted or rejected, with AK3/AK4 segments pointing to the exact segment and element in error.
Version: 4010 vs. 5010
HIPAA originally mandated ASC X12 version 4010A1 for most transactions. The upgrade to version 5010 became mandatory in January 2012 and brought significant structural changes:
ST03(Implementation Convention Reference) was added — required in 5010, absent in 4010- NPI became required in loop 2010AA/BB
- New qualifiers and code sets
- Stricter validation rules
If you’re working with legacy systems, you may still encounter 4010 files. The GS08 version string will tell you instantly: 004010X = 4010, 005010X = 5010.
Putting It All Together
A valid HIPAA X12 file always follows this skeleton, no matter the transaction type:
ISA*...*~
GS*...*~
ST*...*~
[transaction-specific loops and segments]
SE*[count]*[control#]~
GE*[ts-count]*[group-control#]~
IEA*[group-count]*[interchange-control#]~Every character matters. A single missing ~, a mismatched control number, or a delimiter appearing inside a data value can cause the entire file to fail validation before a single claim is adjudicated.
Summary
| Concept | What It Is |
|---|---|
| ISA/IEA | Interchange envelope — outermost wrapper |
| GS/GE | Functional group — groups same-type transactions |
| ST/SE | Transaction set — one business document |
| Loop | Repeating group of related segments |
| Segment | One data record, terminated by ~ |
| Element | One field within a segment, delimited by * |
| Component | Sub-field within an element, delimited by : |
| HL | Hierarchical level linking provider→subscriber→patient |
Understanding this structure gives you the foundation to read any HIPAA X12 file confidently, validate it against the implementation guide, and troubleshoot rejections at the right layer.
Ready to work with EDI files in your browser? Try EDI Paisan free — no install required.