# EDI 275 Claim Attachments: X210 Guide
> EDI 275 claim attachments explained: solicited vs unsolicited, PWK matching, the BGN, TRN, CAT and BIN segments, and the 2026 HHS attachments rule.
The EDI 275 is the X12 transaction a provider uses to send medical documentation that supports a health care claim, such as an operative note or records a payer requested. Today most payers use the 005010X210 guide. A 2026 HHS final rule adopts the 006020X314 version as the HIPAA claims attachment standard, with compliance required by May 26, 2028.
**The EDI 275 is how a claim attachment travels as EDI instead of by fax.** Some claims cannot be paid from the [837](/guides/edi/837-health-care-claim) 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](https://x12.org/products/transaction-sets). 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](https://www.stedi.com/edi/hipaa/transaction-set/275-A9) 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](https://www.federalregister.gov/documents/2026/03/24/2026-05676/administrative-simplification-adoption-of-standards-for-health-care-claims-attachments-transactions)), effective May 26, 2026
- The adopted standards are listed in [45 CFR 162.2002](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-T/section-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](https://www.va.gov/COMMUNITYCARE/docs/providers/HIPAA-Transaction-Companion-Guide.pdf) and [Optum's batch attachments guide](https://developer.optum.com/eligibilityandclaims/docs/batch-draft) 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:
| Item | What the rule says |
|---|---|
| **Transaction defined** | [45 CFR 162.2001](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-T/section-162.2001): attachment information sent by a provider to support a claim, or a health plan's request for it |
| **Envelope for the provider's attachment** | X12N 275 version 6020, `006020X314` |
| **Health plan's request** | X12N 277 version 6020, `006020X313` (Health Care Claim Request for Additional Information) |
| **Document content** | HL7 CDA Release 2 Attachment Implementation Guide (C-CDA based documents), and the C-CDA templates for clinical notes |
| **Electronic signatures** | HL7 CDA Release 2 Digital Signatures and Delegation of Rights, where the provider uses an electronic signature |
| **Scope** | Claims attachments, solicited and unsolicited. The rule was narrowed from the proposed "health care attachments" and does not adopt standards for prior authorization attachments |
| **Effective date** | May 26, 2026 |
| **Compliance date** | May 26, 2028, for all covered entities, with no extra time for small health plans |
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
| | Unsolicited | Solicited |
|---|---|---|
| **Trigger** | Provider knows the claim needs documentation | Payer asks for documentation after receiving the claim |
| **Payer request** | None | A 277 Request for Additional Information (`005010X213` in 5010, `006020X313` under the rule) |
| **`BGN01`** | `02` | `11` (response) |
| **How the 275 is matched** | `TRN02` = the attachment control number the provider put in `PWK06` on the 837 | `TRN02` = the payer's claim control number from the 277 |
| **`STC` in loop 2000A** | Not sent | Required: echoes what the payer asked for, typically as a LOINC code |
| **Patient control number** | `REF*EJ` matches `CLM01` on the 837 | `REF*EJ` matches the value in the 277 |
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](/guides/edi/837-health-care-claim) covers the rest of the claim structure.
The solicited path starts at the payer. Our [277 guide](/guides/edi/277-claim-status-response) 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)
| Loop | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Header | **ST** | Transaction Set Header | Required | `ST01` = `275`, `ST03` = `005010X210` |
| Header | **BGN** | Beginning Segment | Required | `02` unsolicited, `11` response to a request |
| 1000A | **NM1 / PER** | Payer Name and contact | Required / Situational | `NM101` = `PR`. `PER` only when answering a 277 that included one |
| 1000B | **NM1** | Submitter | Required | `NM101` = `41` |
| 1000C | **NM1 / PRV / REF** | Provider name, taxonomy, secondary ID | Required / Situational | `NM101` = `1P`, NPI in `NM109` |
| 1100C | **NX1 / N3 / N4** | Provider address | Required | `NX101` = `1P` in payer samples |
| 1000D | **NM1** | Patient Name | Required | `NM101` = `QC` |
| 1000D | **REF** | Patient Control Number | Required | `REF01` = `EJ`. Must match the claim |
| 1000D | **REF / DTP** | Bill type, medical record number, claim service date | Situational | `DTP*472` service date |
| 2000A | **LX** | Assigned Number | Required, repeats | One per attachment |
| 2000A | **TRN** | Attachment or payer claim control number | Required | The matching key |
| 2000A | **STC** | Status Information | Situational | Required when `BGN01` = `11` |
| 2000A | **REF** | Service line, procedure, modifier | Situational | Ties the attachment to one line |
| 2100A | **DTP** | Service line date | Situational | When dates are by line |
| 2100B | **DTP** | Additional Information Submission Date | Required | `DTP*368` in payer samples |
| 2100B | **CAT** | Category of Patient Information Service | Required | `CAT01` = `AE` (attachment), `CAT02` = format |
| 2110B | **EFI** | Electronic Format Identification | Required | `EFI*05` in payer samples |
| 2110B | **BIN** | Binary Data | Required | Length, then the attachment itself |
| Trailer | **SE** | Transaction Set Trailer | Required | Segment count and control number |
## Key Segments Explained
### BGN: Beginning Segment
```
BGN*02*EFP275000017*20261110~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BGN01** | Transaction Set Purpose Code | `02` | `02` = unsolicited attachment. `11` = response to a payer request |
| **BGN02** | Reference Identification | `EFP275000017` | The submitter's reference for this 275 |
| **BGN03** | Date | `20261110` | Date the 275 was created |
### 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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **CAT01** | Report Type Code | `AE` | `AE` = attachment |
| **CAT02** | Report Transmission Code | `IA` | The format of `BIN02`. `HL` = HL7 (CDA) format, `IA` = electronic image, `MB` = binary image, `TX` = text |
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](/guides/edi/837-health-care-claim), with `PWK` if documentation will follow.
2. Clearinghouse or payer returns a [999](/guides/edi/999-implementation-acknowledgment) 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](/guides/edi/824-application-advice)) for the 275 itself.
6. Payer adjudicates and sends the [835 remittance](/guides/edi/835-health-care-claim-payment-advice). Status in between comes from a [276](/guides/edi/276-claim-status-request) and [277](/guides/edi/277-claim-status-response).
Documentation for prior authorization is a different flow, through the [278](/guides/edi/278-health-care-services-review), and is outside the 2026 claims attachments rule.
## Common 275 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **`TRN02` does not equal `PWK06`** | Attachment cannot be matched; claim pends or denies for missing documentation | Generate the control number once and write it to both the 837 and the 275 |
| **Control number reused across attachments** | Wrong document attached to a claim | One unique control number per attachment |
| **`REF*EJ` differs from `CLM01`** | Match fails at the claim level | Copy the patient control number from the claim record, never retype it |
| **`BIN01` byte count wrong** | Parser fails; whole 275 rejected | Compute the length from the final encoded bytes, after any line breaks are added |
| **`CAT02` not accepted by the payer** | Rejection | Use the formats in the payer's companion guide |
| **Attachment over the payer's size limit** | Rejection | Check the limit; split or compress per the guide |
| **275 sent long after the claim** | Claim already denied | Send unsolicited attachments with or right after the 837, within the payer's window |
| **Solicited 275 missing `STC`** | Payer cannot tell which request it answers | Echo the request in `STC` when `BGN01` = `11` |
| **Real patient data in test files** | Privacy exposure | Test with fictional data, as in this guide's sample |
## 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](/blog/essential-guide-to-edi), and for the other transaction sets, the [EDI document types reference](/edi-document-types).
## 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](/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](/book-call).
## Frequently Asked Questions
### What is an EDI 275?
The EDI 275 is the X12 Patient Information transaction. In health care claims, providers use it to send attachments, such as medical records or an operative note, that support a claim. Most payers today use the 005010X210 implementation guide.
### What is 005010X210?
005010X210 is the X12 implementation guide, version 5010, for the 275 Additional Information to Support a Health Care Claim or Encounter. It defines the loops, segments and codes payers use for claim attachments in current production exchanges.
### Is there a HIPAA standard for claim attachments?
Yes, since 2026. HHS published a final rule on March 24, 2026 adopting X12 275 version 006020X314, X12 277 version 006020X313 and HL7 C-CDA attachment standards for claims attachments. It took effect May 26, 2026, and covered entities must comply by May 26, 2028.
### What is the difference between a solicited and an unsolicited 275?
An unsolicited 275 is sent without a request, because the provider knows the claim needs documentation; BGN01 is 02 and it matches the claim through the PWK06 attachment control number. A solicited 275 answers a payer's 277 request; BGN01 is 11 and STC identifies what was requested.
### How does a 275 match its 837 claim?
For an unsolicited attachment, TRN02 on the 275 must equal PWK06 on the 837, and REF EJ must equal the claim's patient control number in CLM01. The service date in DTP 472 is a further check.
### What goes in the BIN segment of a 275?
BIN01 is the length of the attachment data in bytes and BIN02 is the data itself. Payers specify the content, commonly MIME headers followed by a base64-encoded PDF or TIFF, or a base64-encoded HL7 CDA document.
### Does the attachments rule cover prior authorization?
No. The final rule was narrowed to health care claims attachments. Prior authorization documentation is not covered by the standards adopted in the 2026 rule.