Reference·X12 275·NM1
X12 275 Reference

X12 275 NM1 Explained: Structure, Fields, and Common Mistakes

Jul 28, 2026 · 5 min read

A 275 exists to carry supporting documentation for a claim, and NM1 is the segment that answers the most basic question a reviewer will ask about that documentation: whose records are these? Get the identifier wrong here and the attachment lands in the payer's system with no reliable link to a real patient.

Quick answer

NM1 (Individual or Organizational Name) is a reusable X12 segment that, in a 275 attachment transaction, identifies the patient whose medical records are being sent. It carries the entity role this occurrence represents, the patient's last name, and an identification code such as a member ID, giving the receiving system a way to confirm the attachment belongs to the right person before it gets matched to a claim.

The elements that actually matter in practice

NM101 →
Entity Identifier Code — identifies this NM1 occurrence as representing the patient — see the dedicated page below
NM103 →
Name Last or Organization Name — the patient's last name, used alongside the identification code to confirm identity — see the dedicated page below
NM109 →
Identification Code — a patient identifier such as a member ID, the value systems actually use to match the attachment to a person — see the dedicated page below

Example

Synthetic example Generated by Synthibase
NM1*QC*1*DELACROIX*RENEE****MI*ZH774920163*

A synthetic NM1 identifying the patient (NM101=QC) as Renee Delacroix, with a member ID carried under qualifier MI. Synthetic data only.

Where this trips people up

Because a 275 often travels as a response to a payer's documentation request, teams building test files sometimes populate NM1 with the requesting provider's information instead of the patient's, on the assumption that whoever sent the request already knows who the patient is. The transaction parses without error, but a receiving system that keys attachment matching off the patient's NM103 and NM109 values will fail to associate the records with the correct person, and the attachment effectively goes nowhere.

How to Write EDI Test Cases That Actually Catch Go-Live Failures
How to Validate X12 EDI Files Before Payer Submission
Generate correctly identified 275 attachments
Synthibase produces synthetic 275 transactions with properly populated patient NM1 segments — varied names, varied member IDs, consistently linked — so attachment-matching logic gets tested against realistic identifiers instead of placeholders.
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.