Reference·IN2 Segment·IN2-2
HL7 v2 Reference

HL7 v2 IN2-2 (Insured's Social Security Number): Format, Values, and Testing Notes

Jul 27, 2026 · 4 min read
← IN2-1 IN2-4 →

IN2-2 is a plain text field with zero validation built in, which means the difference between safe test data and a compliance incident comes down entirely to discipline in your data generator.

Quick answer

IN2-2 holds the Social Security Number of the insured party as a simple string, typically formatted as three digits, a dash, two digits, a dash, four digits. HL7 itself imposes no structural validation on the content, so anything from a properly formatted number to a blank field to free text can appear here depending on how the sending system was built.

What this field contains

Data type
ST (String) — no component structure, no built-in checksum or format validation
Typical format
###-##-#### — a formatting convention, not an enforced rule - some sending systems omit the dashes entirely
Test data rule
Never use a plausible real SSN — use an obviously invalid pattern (e.g. a 000 or 900+ area group) so test data can never be mistaken for a real identity

Example

Synthetic example Generated by Synthibase
IN2|EMP-22910|000-45-6789||ACME MANUFACTURING CO||FT

IN2-2 carries 000-45-6789 - an obviously fake SSN pattern using the invalid 000 area-number prefix, safe for use in any shared test environment.

Where this trips people up

Two mistakes show up constantly. The first is generating SSNs that are structurally valid and therefore indistinguishable from a real person's number - a real compliance exposure if that test data ever leaks into a shared environment or log file. The second is the opposite problem: leaving IN2-2 blank across every synthetic record because it feels safer, which means any parsing, masking, or redaction logic your system has for this field never actually runs against populated data until it hits production.

HL7 v2 IN2 Explained: Structure, Fields, and Common Mistakes
How to Build a Synthetic Patient Registry for Healthcare Testing
How to Write EDI Test Cases That Actually Catch Go-Live Failures
Populate IN2-2 without ever risking a real identity
Synthibase always generates structurally obvious, invalid SSN patterns for fields like IN2-2 - so masking and redaction logic gets exercised on populated data, with no real-identity risk.
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.