X12 275 Claim Attachments: How the Transaction Works

X12 275 claim attachments send supporting documents, such as operative notes, to a payer alongside an 837 claim. The 275 is an envelope: a binary segment carries the PDF, image or C-CDA document, and an attachment control number in the 275 matches the PWK segment in the claim. A 275 can answer a payer's 277 request or arrive unsolicited.

This is a reference on the transaction format. Schema Care builds no 275, 277 or 837 files, has no API, SDK, webhooks, FHIR, X12 or 275 output, and does not read insurance cards. Every segment, number and name in the samples is a fictional example, not a real claim or patient.

What the X12 275 transaction is for

The X12 275 transaction carries additional information that supports a health care claim. A provider sends it either in reply to a payer's request, which makes it solicited, or on its own when payer rules say a certain claim needs documentation, which makes it unsolicited. The 275 names the patient, provider, payer and claim the content belongs to.

The X12 transaction set list describes the 275 Patient Information transaction set as able to communicate patient information requests and patient information, solicited or unsolicited, between health care entities, where patient information includes demographic, clinical and other supporting data.

In 2026 the claims version became a HIPAA standard. The CMS fact sheet on the claims attachments final rule (CMS-0053-F) says HHS adopted the X12N 275 Additional Information to Support a Health Care Claim or Encounter, version 006020X314, and the X12N 277 Health Care Claim Request for Additional Information, version 006020X313. It also adopted HL7 C-CDA implementation guides and the HL7 Attachments guide for the content inside. The rule took effect on May 26, 2026, and compliance is required by May 26, 2028.

The final rule in the Federal Register defines the two modes. In solicited transmissions, a provider responds to a health plan's specific electronic request. Unsolicited transmissions have no such request and follow plan requirements set out in trading partner agreements or other guidance. The rule notes that this exchange has remained largely manual, frequently relying on fax, mail or portal uploads.

The 2022 proposed rule for attachments described the design plainly: the 275 does not itself contain the attachment information but serves as the electronic envelope for it, embedded in an HL7 standard. That is still the right mental model. The C-CDA document format itself is compared with FHIR in the section on C-CDA documents and FHIR resources.

Inside a 275 claim attachment: the BIN segment and the file it carries

In the 5010 version of the 275 (005010X210), the attached file travels in a BIN segment, a binary data segment that holds the document as encoded content. The HIPAA-adopted 6020 version (006020X314) includes the Binary Data Segment, BDS, which was not part of version 5010. In both, the segments around the binary data say what the file is.

The VA Office of Community Care 275 companion guide, written for 005010X210, places BIN in loop 2110B. Its rules give a concrete picture of a 5010 attachment:

• CAT02 says what format follows. HL is for HL7 CDA XML documents and IA is for an image sent as base64 in BIN02.
• BIN02 holds the content. For a binary file, the VA expects MIME headers, such as Content-Type: application/pdf and Content-Transfer-Encoding: base64, before the base64 data.
• CDA documents are encoded too. The VA expects the whole CDA attachment base64 encoded.
• Content types are listed. The VA accepts PDF, BMP, GIF, JPEG, TIFF and XML text.

For the 6020 version, the final rule records a commenter's point that Version 6020 includes the BDS, which was not part of Version 5010, and CMS's response that the adopted versions include the BDS, which is used to carry attachments such as documents or images. The 6020 segment layout is defined in the X12 technical report, for which the rule notes X12 charges a fee, so build from that report rather than from a 5010 example.

A 275 envelope with a truncated BIN segment, as an example

The 5010 transaction below is fictional and simplified from the VA's published examples, which also carry address and reference segments. The base64 data is cut short, and the identifiers are invented.

ST*275*0001*005010X210~
BGN*02*EXBGN0042*20261015~
NM1*PR*2*EXAMPLE HEALTH PLAN*****PI*EXPLAN01~
NM1*41*2*EXAMPLE BILLING SERVICE*****46*EX12345~
NM1*1P*2*EXAMPLE FAMILY CLINIC*****XX*1234567893~
NM1*QC*1*EXAMPLE*NORA****MI*EXM300400500~
LX*1~
TRN*1*EXACN2026101500042~
DTP*368*D8*20261015~
CAT*AE*IA~
EFI*05~
BIN*48211*MIME-Version: 1.0
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=ex-operative-note.pdf

JVBERi0xLjcKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+...~
SE*13*0001~

A real file also needs ISA and GS envelopes and their trailers. Where X12 envelopes define their delimiters is explained in the section on where the 835 envelope defines its delimiters; the same rules apply to a 275.

How does a 275 attachment link back to its 837 claim?

A 275 attachment links to its 837 claim through one shared value, the attachment control number. The provider puts it in the claim's PWK segment, in PWK06, and puts the same value in the 275's TRN segment. The payer matches the two. If they differ by a single character, the attachment and claim do not meet.

The VA companion guide states the rule exactly: TRN01 must be 1, TRN02 must be the attachment control number, and TRN02 must equal PWK06 in loop 2300 of the associated 837. The Minnesota AUC best practice on claims attachments adds that PWK06 allows up to 50 characters, that providers create attachment control numbers with their own scheme, and that each must be unique for a particular attachment within a billing provider.

The claim side of the fictional example looks like this. Only the claim and PWK lines are shown:

CLM*EX-2026-0099*640***11:B:1*Y*A*Y*Y~
PWK*OB*EL***AC*EXACN2026101500042~

The PWK02 value has a history worth knowing. CMS Transmittal 2050, effective July 2018, told Medicare contractors to publish EL for an esMD submission using the X12 275 and FT for a PDF sent by file transfer. At that time it said EL was reserved for future use, so check a payer's current companion guide before relying on it. The same transmittal says only the first PWK iteration, at claim or line level, is considered in adjudication.

Where PWK sits among the other 837 loops is covered in the section on the 837 loop structure from billing provider to service line, and the wider guide to X12 837 generation covers building the claim itself.

The 277 request for additional information and the 275 reply

In a solicited exchange, the payer sends a 277 asking for specific documentation, and the provider answers with a 275 that carries it. The reply must echo the identifiers the request supplied, above all the payer's tracking number, so the payer can match it to the pended claim. A reply that uses the provider's own number may never be matched.

The X12 transaction set list says the 277 can be used by a payer to request additional information from a provider about a claim or encounter. The adopted HIPAA version is 006020X313, per the CMS fact sheet. The 2022 proposed rule walks through the flow: when a plan solicits attachment information, the provider replies to the X12N 277 request using the X12N 275.

The HL7 Da Vinci Clinical Documentation Exchange guide shows which number to echo. Its CDex sending attachments page, version 2.1.0 (STU 2.1) and the current published release, maps its fields to the 6020 275. It places the tracking ID in loop 2000A, TRN02, and says that for unsolicited attachments it is the provider-assigned control number, while for solicited attachments it is the payer-assigned one. It also places the LOINC attachment code in STC01-01 in loop 2000A.

A careful reply handler does four things:

1. Store the 277's identifiers with the pended claim. Tracking number, claim reference, requested attachment code and due date.
2. Gather exactly what was asked. A request for an operative note is not answered by the full chart.
3. Build the 275 from stored values. Copy the payer's tracking number into TRN02 rather than retyping it.
4. Track the response window. A late reply may not be considered.

Not every receiver handles both modes. The VA guide says its program does not send 277 requests and will not process solicited 275 transactions, which it identifies by the value 11 in BGN01.

Which payers accept X12 275 claim attachments, and what are the alternatives?

Acceptance of X12 275 claim attachments varies by payer and clearinghouse, so check each payer's companion guide. Medicare's esMD instructions define PWK codes for 275s, and the VA publishes a 275 guide. HIPAA compliance is due May 26, 2028. Until a payer accepts 275s, the alternatives are portals, fax, mail and, in some programs, FHIR exchange.

The government programs are documented. CMS Transmittal 2050, from 2018, set business requirements for Medicare contractors to receive unsolicited documentation through esMD, with a waiting period of seven calendar days when PWK02 is EL or FT. Because it called EL reserved for future use at the time, confirm current 275 support with your Medicare contractor. The VA companion guide covers unsolicited 275s for its community care program. For commercial and Medicaid plans, the companion guide of each plan or clearinghouse says whether and how they accept them.

The final rule changes the picture over time. The rule says that once the compliance date of May 26, 2028 is reached, all covered entities are legally required to use the adopted standards when they conduct claims attachment transactions electronically. It also notes that providers may choose not to conduct transactions electronically. Read the rule itself for how it applies to your organization; this post does not give legal advice.

The alternatives in use now:

The CDex guide says its FHIR operation is used for both solicited and unsolicited attachments and is intended to be compatible with the X12N 275 and 837 transactions, given the right identifiers. Its page on solicited and unsolicited attachments notes that a payer can also request attachments through an X12 transaction, fax, portal or other platform. FHIR's other bulk tools, such as FHIR bulk data export, move data out of servers and do not deliver claim attachments.

At the front of the pipeline, attachments arrive as paper. How claim attachments and supporting documents get split and linked at intake is covered in the section on how claim attachments and supporting documents should be split and linked. Schema Care reads insurance claims, the CMS-1500 and UB-04 fields with their diagnosis and procedure codes, and sends uncertain fields to a reviewer, as listed with the other document types Schema Care reads. Building the 837 and 275 is left to your billing system.

275 attachment mistakes: mismatched control numbers and oversized files

Most lost 275 attachments come from two mistakes: an attachment control number that does not match the claim's PWK06 exactly, and a file larger than the receiver accepts. Both are easy to prevent in code. Generate the number once, copy it into both transactions, and check file size against each receiver's companion guide before sending.

Control number mistakes take several forms:

• Retyping instead of copying. A dropped digit in either PWK06 or TRN02 breaks the match.
• Reusing a number. The Minnesota best practice requires a unique number for each attachment within a billing provider.
• Using too many characters. PWK06 allows 50.
• Sending the attachment without the claim. The VA guide says it tries to match an unmatched 275 to incoming claims for up to 7 days, after which the attachment is orphaned and will not support payment of any claim received later.
• Resubmitting a claim alone. The VA guide says a resubmitted claim must be sent with its 275 attachment again.

Size and count limits come from each receiver. The VA guide rejects any 275 with a single attachment larger than 64 megabytes, advises splitting larger documents into pieces under that size sent in order within one 275, and accepts up to 10 BIN segments per transaction per claim. Other receivers set their own limits, so keep them in configuration per payer.

Other failures worth guarding against:

• Wrong content type. A file labeled as PDF that is really a TIFF may fail at the receiver.
• Building from the wrong version. A 5010 BIN example does not describe the 6020 BDS layout.
• Losing the trail. Store the control number, file name, 275 control numbers and any 999 acknowledgment with the claim, so a rejection can be traced.

The fields that start this chain are often keyed from paper: member IDs from cards, as in the guide to an insurance card OCR API, and claim fields from forms. Checking those values before they reach the 837 prevents a matched attachment from supporting a claim that was wrong to begin with.