EDI 275 Claim Attachments: X210 Guide

The EDI 275 is how a claim attachment travels as EDI instead of by fax. Some claims cannot be paid from the 837 alone: the payer needs an operative report, a certificate of medical necessity or the records from the visit. The 275 wraps that documentation in an X12 envelope, ties it to the claim with a control number, and sends it to the payer either with the claim (unsolicited) or in answer to the payer's request (solicited).

This guide covers what the 275 carries, the regulatory status of attachments under HIPAA, how the 275 links to the 837 and the 277, every segment in the 005010X210 implementation guide, a live example built from fictional data, and the matching errors that leave attachments orphaned. It describes the X12 structure only; it is not legal, billing or compliance advice.

What Is an EDI 275?

An EDI 275 is the Patient Information transaction set defined by ASC X12. In health care claims it is implemented through the X12N Technical Report Type 3 005010X210, Additional Information to Support a Health Care Claim or Encounter. It carries a claim attachment: clinical or administrative documentation that the claim itself has no room for. The functional group code in GS01 is PI, and GS08 and ST03 carry 005010X210.

Authoritative references for 275 work:

• The Stedi 005010X210 reference lists every loop and segment, and notes that for an unsolicited 275 the attachment control number is the value from PWK06 in loop 2300 of the 837
• HHS published the claims attachments final rule on March 24, 2026 (91 FR 14350), effective May 26, 2026
• The adopted standards are listed in 45 CFR 162.2002, "for the period on and after May 26, 2028"
• Payer companion guides set the working rules for today's 005010X210 exchanges. The VA Office of Community Care companion guide and Optum's batch attachments guide are two public examples

Who sends it? The provider, usually through its clearinghouse or practice management system.

Who receives it? The health plan, or the clearinghouse or attachment vendor acting for it.

When is it sent? With or just after the 837 when the provider knows documentation is needed (unsolicited), or after the payer asks for it (solicited).

Why does it matter? A claim waiting for documentation is a claim not getting paid. An attachment that cannot be matched to its claim is as good as never sent, and the claim may be denied for missing information.

Where Claim Attachments Stand Under HIPAA

For most of HIPAA's history there was no adopted standard for claim attachments. Payers accepted documentation by fax, mail, portal upload, or a 275 built to their own companion guide, almost always on the 5010 version, 005010X210.

That changed with the HHS final rule Administrative Simplification; Adoption of Standards for Health Care Claims Attachments Transactions and Electronic Signatures, published March 24, 2026. Per the rule and the new Subpart T of 45 CFR Part 162:

So the practical position in late 2026 is: production attachment exchanges run on 005010X210 under each payer's companion guide, and the industry has until May 26, 2028 to move to 006020X314 and 006020X313 with C-CDA content. The example in this guide uses 005010X210 because that is what payers accept today. The overall pattern (envelope, claim matching, attachment payload) carries over to 6020, but the segment-level details of 006020X314 come from that TR3, not from this page.

Solicited and Unsolicited Attachments

The unsolicited path starts on the claim. In the 837, a PWK segment in loop 2300 (claim level) or 2400 (service line) tells the payer documentation exists and how it will arrive:

PWK*OB*EL***AC*EFPATT0001~

PWK01 is the report type (OB is an operative note), PWK02 the transmission code (EL = electronically only), PWK05 = AC (attachment control number) and PWK06 the control number itself. The 275 then carries the same value in TRN02. Our 837 guide covers the rest of the claim structure.

The solicited path starts at the payer. Our 277 guide covers the 277 claim status response and 277CA; the request-for-information variant uses the same transaction number with its own implementation guide.

Interactive Example: Unsolicited Claim Attachment (275, 005010X210)

A fictional family practice sends documentation for claim EFP26110902, which its 837 flagged with PWK06 = EFPATT0001. BGN01 = 02 marks it unsolicited. The four name loops identify the payer (PR), the clearinghouse that submits it (41), the provider (1P) with its address, and the patient (QC). REF*EJ repeats the claim's CLM01 and TRN02 repeats the attachment control number. CAT*AE*IA says the attachment is an electronic image, and BIN carries it. Every name, ID and value is fictional, ISA15 is T (test), and the BIN payload is a short base64 placeholder rather than a real document.

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

275 Structure at a Glance (005010X210)

Key Segments Explained

BGN: Beginning Segment

BGN*02*EFP275000017*20261110~

NM1 and REF: Who and Which Claim

NM1*QC*1*SAMPLE*JORDAN****MI*ZZM000111222~
REF*EJ*EFP26110902~
DTP*472*D8*20261109~

The patient loop identifies the person and, through REF*EJ, the claim. On an unsolicited 275 the patient control number must equal CLM01 on the 837. The service date in DTP*472 gives the payer a second matching point. The payer and provider loops follow the same conventions as the 837: payer ID in NM109 with qualifier PI, provider NPI with qualifier XX.

TRN: The Matching Key

TRN*1*EFPATT0001~

TRN02 is what the payer uses to attach the document to the claim. For an unsolicited 275 it must equal PWK06 on the 837, character for character, and it must be unique per attachment. For a solicited 275 it carries the payer's claim control number from the 277 request. Payer samples, including the VA and Optum guides, use TRN01 = 1.

CAT: What Kind of Attachment

CAT*AE*IA~

Payers restrict CAT02. The VA guide accepts HL, IA, MB and TX; other guides require one value for images. Check the payer's companion guide before choosing.

EFI and BIN: The Attachment Itself

EFI*05~
BIN*140*RklDVElPTkFMIFRFU1QgQVRUQUNITUVOVC4g...~

EFI01 is a security level code; 05 (personal) is the value in payer samples. BIN01 is the length of the data in bytes and BIN02 is the data. The receiving translator reads exactly BIN01 bytes after the separator, which is why BIN02 can contain characters that would otherwise look like delimiters. If the count is off by even one byte, the parser reads into the next segment or stops short, and the whole transaction fails.

What goes inside BIN02 is set by the payer:

• MIME with base64. Optum and the VA describe MIME headers (content type, transfer encoding, file name), a blank line, then the base64-encoded file. The raw PDF or TIFF bytes are not placed in the EDI directly.
• CDA documents. With CAT02 = HL, the content is an HL7 CDA document, which the VA expects to be base64 encoded in full.
• Payer XML wrappers. Some state Medicaid programs define their own XML envelope around the file.

Size limits are also payer-specific. The Optum, VA and Arizona AHCCCS guides state 64 MB per attachment, and Texas Medicaid's guide states 50 MB.

Where the 275 Sits in the Claim Cycle

1. Provider sends the 837 claim, with PWK if documentation will follow.
2. Clearinghouse or payer returns a 999 for the claim file and a 277CA for each claim.
3. Unsolicited: provider sends the 275 with the matching attachment control number.
4. Solicited: payer sends a 277 request for additional information, and the provider answers with a 275 (BGN01 = 11).
5. Payer returns a 999 (or, for some payers, an 824 application advice) for the 275 itself.
6. Payer adjudicates and sends the 835 remittance. Status in between comes from a 276 and 277.

Documentation for prior authorization is a different flow, through the 278, and is outside the 2026 claims attachments rule.

Common 275 Errors and How to Prevent Them

275 Implementation Checklist

• Get each payer's 275 companion guide: version, CAT02 formats, BIN02 content rules and size limits
• Confirm whether the payer accepts unsolicited 275s, solicited 275s, or both
• Generate attachment control numbers once, and write them to PWK06 on the 837 and TRN02 on the 275
• Carry the patient control number and service date from the claim record
• Encode attachments exactly as the guide specifies and compute BIN01 from the final bytes
• Handle 277 requests for additional information and answer with BGN01 = 11 and STC
• Process 999s (and 824s where used) for 275 files
• Plan the move to 006020X314, 006020X313 and C-CDA content before May 26, 2028
• Test unsolicited, solicited, multi-attachment and rejected scenarios with fictional data

For an introduction to X12 structure, see our essential guide to EDI, and for the other transaction sets, the EDI document types reference.

Where OrderSync Fits

OrderSync's product is built for supplier order flows: it reads inbound purchase orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units, and outputs ERP data or valid X12.

For healthcare EDI teams, the useful piece is the free EDI inspector, which parses any X12 file, 275s included. Paste a test 275 to see the payer, provider, claim and attachment control numbers and the attachment format explained segment by segment. Follow your organization's policies on protected health information before pasting a production file; test files with fictional data work just as well for checking structure. To talk through an order-side workflow, book a 15-minute walkthrough.

Frequently Asked Questions