HL7 v2 IN1 Segment Guide: Fields, Format, and Testing Gotchas

Jul 27, 2026 · 6 min read

A single missing pipe in an IN1 segment can push a policy number into the wrong field and quietly break eligibility checks downstream — and nobody notices until a claim bounces weeks later.

Quick answer

IN1 is the HL7 v2 segment that carries insurance and coverage details for a patient encounter — payer identity, group and policy numbers, coordination-of-benefits priority, and the insured party's relationship to the patient. It typically rides inside ADT and DFT messages, one IN1 segment per coverage, ordered by IN1-1.

The fields that actually matter in practice

IN1-1 →

Set ID — orders multiple IN1 segments when a patient carries more than one payer; primary coverage is usually 1

IN1-2 →

Insurance Plan ID — coded plan identifier plus free text — often the field downstream eligibility logic keys off

IN1-3 →

Insurance Company ID — the payer's internal or clearinghouse-assigned identifier, distinct from the plan ID

IN1-4 →

Insurance Company Name — free-text payer name; frequently inconsistent across sending systems, which is where matching bugs hide

IN1-8 →

Group Number — employer or policy group identifier; commonly left blank or malformed in real-world feeds

IN1-17 →

Insured's Relationship to Patient — coded value (self, spouse, child, other) that determines whether patient and subscriber demographics should match

IN1-36 →

Policy Number — the subscriber's policy identifier, often confused with group number in test data generators

Example

Synthetic example Generated by Synthibase

IN1|1|PPO2200^ACME REGIONAL HEALTH PLAN^ACMEID|66214|ACME REGIONAL HEALTH PLAN||||GRP-9042217||||||||DOE^JANE^M|01|||||||||||||||||||POL-77213840

A synthetic IN1 segment for a single primary payer: plan PPO2200 with Acme Regional Health Plan, group GRP-9042217, insured Jane M. Doe as the subscriber (relationship code 01 = self), and policy POL-77213840.

Where this trips people up

Two things break IN1 test coverage more than anything else. First, teams generate a single "happy path" IN1 with relationship code 01 (self) and never exercise 02 (spouse) or 03 (child), so any logic that cross-checks patient and subscriber demographics goes untested until a dependent's claim fails in production. Second, group number and policy number get swapped or conflated in synthetic data sets because both are free-text ST fields with no format enforcement — your test data needs to keep them distinct even though HL7 itself won't stop you from mixing them up.

→

How to Reduce Claim Denials Through Better Pre-Submission Testing

→

COB Claims Testing: How to Generate Coordination of Benefits Scenarios

Generate realistic IN1 segments without touching real patient data

Synthibase produces synthetic HL7 v2 messages with valid, varied IN1 coverage scenarios — multiple payers, dependent relationships, and edge-case group numbers included — so your test suite covers what production actually sends.

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.