Change Healthcare Batch Attachment Electronic Interchange Companion Guide

January 2022

Table of Contents

What This Guide is About

Supported EDI Transactions
Basic Requirements for Batch 275 Submissions
What we Recommend
Timing of Submissions to the Payer

Batch 275 Submission Requirements

Attachment File Requirements
Attachment File EDI Requirements

Setting Up Your SFTP

SFTP Setup Details

Building the Batch 275 Submission

Defining the Claim Information
Details for Legacy Relay Health Clients
Building the BIN Segment
Entering MIME headers in the BIN segment
Encoding the Attachment File
Setting Up LX Loops in a Claim-Level Transaction
Annotated EDI 275 Submission
Supporting Multiple Claims
Supporting 837 Service Line Information
Payer-Specific Requirements

Interpreting a 999 Response

Change Healthcare Client Checklist
Key Terminology
Batch 275 Submissions FAQ


Change Healthcare Corporation provides the information in this document for business processes education and awareness. We wrote this with the goal to provide our customers with the complete information to successfully deliver and manage Unsolicited Version 5010 ASC X12 275 batch attachment submissions. While Change Healthcare believes all information in this document to be accurate at the time of writing, it is intended for educational purposes only, and we cannot warranty its accuracy or completeness. The information in this document is for reference use only. We also observe the "If not required by this Guide, do not send" standard set forth in the X12 standards guides.

Also, the listing of an organization in this document doesn't imply an endorsement, business relationship or recommendation. Change Healthcare takes no responsibility for any third-party tools, products, or Internet web sites that we may mention in this document. Existence of a link or organizational reference in any part of this Guide is not an endorsement by Change Healthcare.


The ASC X12 Technical Reports Type 3 (TR3s) defines rules for the format, content, and data element of 5010 ASC X12 transactions. These guides are available on the X12.Org website; go here for licensing information.

This document supplements the ASC X12 TR3s for Change Healthcare customers and describes aspects of the Change Healthcare network environment, use cases, interchange requirements, transaction responses, acknowledgements, and reporting for each of the transaction types specified in this guide as they're related to Change Healthcare. This guide also documents specific information for data elements and values required by Change Healthcare.

For this document's purposes, readers must have a subscription to Washington Publishing Company and to the 275 and 999 TR3 Guides, along with the appropriate 837 TR3 Guides.



As defined in the ASC X12 TR3s, we designed this document to supplement, not replace, the standard ASC X12 TR3 for each transaction set. Information in this guide does not change or augment definitions, data conditions, or usage of any data element or segment from the standard TR3s. This Guide does not define or use any code or data values that are not valid in the standard TR3s, or change the meaning or intent of any TR3 specifications.

What This Guide is About

An attachment is a document, such as a photograph or a descriptive piece of writing, created to corroborate performance of medical care. Providers send these documents to insurance companies to help adjudicate and determine payments to the providers.

You can submit ASC X12 275 transactions using a Batch format, called a batch 275 submission. Use batch 275 submissions to support multiple 837 claims with documentation. This document describes in detail how to create and submit batch 275 submissions.

Benefits from Using this Guide

As a medical provider, with regular requirements to send attachments for your submitted medical claims, you will get the following benefits from this Change Healthcare Guide:

  • Repeatably perform batch 275 submissions
  • Improve the timeliness of claim handling
  • Avoid common errors and problems when sending attachments in batch format
  • Reduce shipping/postage and material costs
  • Fewer claim payment delays due to problems sending supporting content
  • Improved claim payment cycles and reduced incidence of appeals

Supported EDI Transactions

This User Guide refers to the ASC X12 Technical Reports Type 3 based on Version 005010. The following transaction types are supported in this document:

EDI Transaction TypeSupported VersionTransaction Title
ASC X12N 275


Additional Information
to Support a Health
Care Claim or
Encounter (275)
ASC X12C 999


Implementation Acknowledgment
For Health Care Insurance (999)

Using this document, you can submit Unsolicited attachments of medical documentation to support a medical claim. An Unsolicited attachment means that the contents you're sending are not requested by the insurance payer. Because you can send multiple documents at a time, and send documents for multiple 837 claims, these collections are called a batch 275 submission.



When necessary, Change Healthcare can translate ASC X12 005010X210-version 275 submissions to the 006020X314 version of the ASC X12 275 TR3 standard. While this Companion Guide directly supports the 275 5010 version, some payers newer to electronic attachment processes use the 275 6020 version. Change Healthcare translates automatically when needed.

The following diagram provides a basic illustration of the data flows through Change Healthcare's network:


Basic Requirements for Batch 275 Submissions

You will need the following to perform the tasks described in this Guide:

  • A contractual relationship with Change Healthcare;
  • A standard SFTP application that supports Secure SFTP;
  • An electronic SFTP mailbox assigned by Change Healthcare that you use to submit batches, and to receive acknowledgments for your submissions;
  • Team knowledge of EDI sufficient to craft the 275 submission and to interpret 999 responses from Change Healthcare or from the payer.

Contact your Change Healthcare sales representative for information about getting started.

What We Recommend



Payers typically do not have restrictions on which submissions they receive first, but sending and verifying that the 837 claim is accepted before sending attachments ensures good payer relations, and eliminates confusion in processing and adjudicating claims.

Change Healthcare directly supports the best practice in which you send the 275 batch submission after the 837 claim has been submitted to and accepted by the insurance payer. Doing this ensures the claim is established in the payer's database so it can be referenced when you send the batch of content.

Claims submissions through Change Healthcare (through a Medical Network API, for example) are completely separate from submitting batch attachments to support those claims, so you may want to verify claim acceptance before proceeding. Following this practice helps avoid the event of a payer rejecting the claim only to then receive an attachment submission.

We recommend submitting the 837 claim prior to submitting attachments.

Timing of Submissions to the Payer

Some payers impose a time limit on attachments that they receive before the claim. If you submit the claim before sending the attachments, payers may use the 275 transaction's Loop 2000A TRN02 entries to match against the correct services for the healthcare claim. A match successfully associates the two records.

If a payer does not find or receive a match, they may hold the attachment for a specified time period. Then, they typically run automatic rematch attempts during that time period. If the 837 claim does not appear in a timely manner, the attachment may be "orphaned" and won't be used even when a matching claim appears. In this case, you must resubmit the batch.



Some payers will, as a matter of policy, require attachments to be submitted after a claim is established in their system. Some payers will accept and match 275 attachment submissions when they are sent with the claim. Every payer differs in how they manage and define their claim documentation, so ensure that you know your payer's policies.

If Change Healthcare's clearinghouse receives both the 837 claim and the 275 submission at the same time (or if the 275 batch appears first), Change Healthcare will hold the incoming attachment for at least 12 hours. Doing so ensures that the clearinghouse processes the claim first. When the 837 is established in the system, Change then processes the 275 so that the match can work before everything is sent to the payer.

Batch 275 Submission Requirements

You can use Change Healthcare batch attachment processes to support claims to any insurance payer, whether or not they are contracted with Change Healthcare. It also extends to payers who support submission of electronic 837 claims but that do not support electronic attachment submissions. Change Healthcare also supports print and mail/fax processes for any payer when necessary.

The following requirements apply to all batch 275 submission files submitted through Change Healthcare.

  • All batch 275 submissions are unsolicited
  • You must be able to read and process 999 responses

Attachment File Requirements

Check with your Change Healthcare representative if you have any questions about the following requirements:

  • Complete Batch EDI files must use the *.275 file extension
  • File names for all completed Batch 275 EDI files sent to Change Healthcare must begin with the string CHC_IMNA_275_ (case-sensitive), example: CHC_IMNA_275_13794048N4.275
  • The file name can be up to 50 characters
  • Clients using the Relay Health clearinghouse must insert the following string at the beginning of each Batch 275 EDI file: CHC_MA_275_
  • Do not use ZIP files

Attachment File EDI Requirements

  • Each individual attachment requires a set of standard MIME headers, which are metadata information describing the document contents. You enter them in each attachment's BIN segment;
  • The MIME headers for attachments must have an ASCII CR/LF character between each header;
  • Attachment image data must be BASE64 binary-encoded, and formatted at 76 characters per line;
  • Each line of encoded attachment data must end with the ASCII CR/LF character.

Other EDI requirements include the following:

  • You separately submit 837 claims and unsolicited batch 275s. In this case, each has their own ISA/IEA envelope and separate GS/GE envelope;
    • For any 275 batch sent to a payer, element ISA15 in the ISA interchange control header must contain the value P to denote production;
    • The Submitter ID must be in ISA06 of the ISA envelope. Get the correct Submitter ID value from your Change Healthcare representative;
  • Ensure you use the correct Payer ID value for your submission. If necessary, check with your Change Healthcare representative to ensure you have the correct Payer ID values. This also extends to payers who do not support electronic attachment submissions, as noted above.



A batch 275 submission can contain several 275 transactions. Each 275 transaction associates with a medical claim, and can have multiple attachments.

Individual 275 transactions in the batch submission will have the following characteristics:

  • The batch 275 submission supports one or more ST/SE envelopes. Each ST/SE envelope represents a unique 275 transaction tied to an 837 claim;
  • All 275 transactions in a batch support one (1) attachment per service line level;
  • To support multiple attachments for the same 837 claim, use multiple 2000A LX loops in any single ST envelope. It means that you can send attachments for multiple service lines in any claim;
  • Each 2000A LX loop contains a single BIN segment with a single attachment;
  • Each LX loop contains a reference to a specific service line from the 837 claim;
  • LX loops can define attachments that apply to the entire claim (matching against 837 Loop 2300 PWK06) or that apply to individual medical services (matching against 837 Loop 2400, Line Item Control Number REF segment);
  • The BIN segment in an LX loop contains the Base64-encoded attachment content. It also contains the MIME headers that define the attachment information.

We provide a complete example below.

Setting Up Your SFTP

When you submit a new 275 batch file by SFTP, you are securely uploading the data to the Change Healthcare SFTP site, where your file is automatically picked up by Change Healthcare and forwarded to the correct health plan.

Change Healthcare's SFTP server is It supports only SSH-FTP. For submitting Batch 275s, you will use password authentication. Your SSH key pair will also be given to you by your Change Healthcare representative.

SFTP Setup Details

Port: 22 (standard SFTP)

File naming conventions:

  • The file suffix must be *.275

  • Ensure that the file is named properly before you upload

  • Do not use the following characters in any file name:

    ‘ “ ( ) [ ] { } / , $ @ & = + * # ! % ` | ? < > ; or spaces

The folder structure you will need for your files is as follows:


You submit complete batch 275 EDI files in plaintext to the /clearinghouse/inbound/275ima folder. Do not encapsulate the 275 as a ZIP file.

Your received 999s will be in the /clearinghouse/outbound folder.

After you download your 999s and other responses, those files will be moved to the /clearinghouse/outbound/archive folder. You can retrieve them from there in the event you need to do so.

When you upload files for the payer, the Change Healthcare clearinghouse will access them. Ensure you keep permanent records of your electronic submissions for future reference.

Building the Batch 275 Submission

Four main components comprise an Unsolicited Batch 275:

Each of these submission components contains important details without which your batch 275 submission won't be accepted by the payer. This section takes a 'cookbook' approach, describing how to develop each of the four main sections of the 275 in turn. We illustrate using annotated EDI, with all requirements needed for a successful transaction.

Defining the Claim Information

Every batch 275 submission supports one or more 275 transactions. You will only cite the claim information once for each transaction. It will be similar to the following:

ISA*00*          *00*          *ZZ*123456789      *ZZ*112233445   
*220101*1151*^*00501*0001223344*0*P*:~                          <-- ISA envelope
GS*PI*123456789*113355779*20220101*1151*112233*X*005010X210~    <-- GS envelope
ST*275*0001*005010X210~                              <-- ST is the transaction header!
BGN*02*1122334455667788*20220101~                    <-- Beginning of transaction 
NM1*PR*2*EXTRA HEALTHY INSURANCE*****PI*9496~        <-- Payer info
NM1*41*2*REGIONAL PPO NETWORK*****46*123456789~      <-- Submitter info 
NM1*1P*2*HAPPY DOCTORS GROUP*****XX*1122334455~      <-- Provider info
N3*200 2nd St Apt 2~                                 <-- Provider address info
N4*SECOND CITY*IL*22222-2222~
NM1*QC*1*PATIENT*HAPPY****MI*123456789~              <-- Patient info
REF*EJ*C1122334455667~                               <-- Patient control number
DTP*472*RD8*20200622-20200623~                       <-- Service date

The submitter identifiers for the ISA, the GS, and the NM1 41 segments will be provided by your Change Healthcare representative.

Related details for correct claim information:

  • As noted, your batch 275 submission uses a single ISA/IEA envelope and a single GS/GE envelope, no matter how many 275 transactions are involved;
  • An ST segment initiates each 275 transaction. It is the transaction header. It contains the following:
    • The BGN segment defines the transaction as Unsolicited (BGN01=02). It is the first segment in the 275 transaction. The Unsolicited value is the default for all your transactions;
    • The NM1 segments describe:
      • The Payer (NM101=PR) with their Payer ID (9496 in this example). Set this to be the destination payer ID;
      • The Submitter (NM101=41) for the transactions described in this document; This value also goes in ISA06 of the batch's ISA header. Get the correct Submitter ID value from your Change Healthcare representative;
      • The Provider (NM101=1P) that originates the 275 content. If the provider has an NPI, it must be inserted in NM109;
    • N3 and N4 contain the provider's address information;
    • The final NM1 segment identifies the patient (NM101=QC) along with their insurance ID number;
    • The REF segment provides the patient control number, which must match element CLM01 of the 2300 loop in the 837 claim (REF01 = EJ);
    • DTP defines the claim services date. The date may be a range as shown here.

If the provider does not use an NPI, submit their provider number using the REF Provider Secondary ID segment. It uses REF01=A6.



For Legacy Relay Health clients - for any batch 275 submissions, ensure that the ISA08 element contains the following value: ATTBATCH (left justified with 7 spaces).

This will be the default Interchange Receiver ID value for all batch submissions. Contact your Change Healthcare representative if you have questions about this item.

For details on each segment and on the EDI Control Segments, see the ASC X12 275 Technical Report Type 3.

Building the BIN Segment

The BIN segment contains the attachment payload. It consists of two main parts:

  • The MIME headers (metadata) for the attachment
  • The encoded attachment data

All attachment information must be MIME-packaged. Check IETF RFC 2045 for details about MIME headers.

Entering MIME headers in the BIN segment



Click here for more information about MIME headers.

Using a set of Multipurpose Internet Mail Extensions (MIME) headers, you 'package' the entire contents of an encoded attachment file. You place them at the beginning of the text contained in the BIN02 element, just ahead of the encoded file data. Here is an example of the exact MIME header set:

Mime-Version: 1.0
Content-Type: application/pdf 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename=yourfilename.pdf


This information is also called metadata. It does not affect the size or format of the file contents; it is used for vital descriptive information about the attachment. Every attachment sent in a batch must have its own set of metadata and it must be formatted exactly as shown.



Make sure to have a CR/LF between each line of the MIME headers.

The MIME headers look much the same in the BIN segment:


BIN*6553512*Mime-Version: 1.0~                <-- BIN segment with file size
Content-Type: application/pdf~                    
Content-Transfer-Encoding: base64~
Content-Disposition: attachment; filename=right_arm_1.pdf/9j/4AAQSkZJRgABAAEAlgCWAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/2wCE
DQ0NDQ0NDQ0BBQgICgcKDAcHDA0MCgwNDQ0ND...~    <-- Attachment data 

You enter the attachment file size, in bytes, into the BIN01 element; in this example it is 6553512, or 6.5 MB.

Note that the carriage returns following each line of the headers. You must also insert a double CR/LF character sequence (a complete blank line) between the last MIME header and the beginning of the Base64 content data.

Encoding the Attachment File

You do not "attach" the image file or PDF file to the 275's BIN segment as you would to an email; you must convert the document file to Base64 encoding. It changes the file format to be compatible with Change Healthcare's network while retaining the integrity of the attachment content.

Copy and paste the raw encoded data from your file into the BIN02 element.



If needed, Google using the term "base64 encoding tool" for more information.

When you encode the file, do the following:

  • Ensure that the conversion uses the CRLF (Windows) standard;
  • Choose the option to split all lines of data into 76 characters per line.
  • The size limit for any single encoded attachment file is currently 64 MB.
  • Some medical submissions encompass a very significant number of service lines, resulting in documentation that can be many pages in length. Lengthy hospital stays can yield thousand-page PDFs of total attachment information. Fortunately, since each service line needs its own specific docs,
  • Use one BIN segment for each attachment file. To see how an LX loop containing a BIN segment is structured, please see the following section.

If you are sending more than one attachment in any 275 transaction in the batch, also see the following section.

Setting Up LX Loops in a Claim-Level Transaction



For multiple documents to support a single claim, the 837 claim must use multiple PWK segments.

A set of LX loops supports sending multiple attachments for a claim. Each LX loop contains a single BIN segment, with other vital information. The BIN segments contain a single unique document. You can have multiple LX loops within any single 275 transaction. This gives you more flexibility in how you can send attachments to payers.

You can use LX loops in two contexts:

  • Claim-level attachments (matched against 837 Loop 2300, element PWK06)
  • Line-level attachments (Matched against 837 Loop 2400, Line Item Control Number REF segment, elements REF01 and REF02.)

The 2000A LX segment Assigned Number segment contains the value defining each attachment loop (attachment #1, Attachment #2, etc...). It increments by 1 for each attachment.

An example:

LX*1~                  <-- Increment this value for each loop
TRN*1*1234567~         <-- This refers to the 837 service line for the attachment 
CAT*AE*MB~             <-- Describes the content in the BIN segment
BIN*88487*Mime-version: 1.0    <-- BIN segment starting with MIME headers
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=right_arm.pdf


Each LX segment consists of an incremented value (the assigned number) with looping starting at 1.



The LX loop's TRN segment contains the all-important reference to an 837 claim's Service Line that the attachment is documenting. It consists of the value that resides in the service line's Loop 2300 PWK06 element (PWK segment). Note that this is represented at the claim level (Loop 2300), and not the line level (Loop 2400).

Annotated EDI 275 Submission

This example describes how you define Claim Supplemental Information to support one claim, represented by one ST segment. It delivers multiple attachments (two in this example). The attachments are defined this way because they apply to the entire claim and not to individual medical services.

Each LX loop uses a TRN segment to call out the PWK06 element from a claim-level service in the 837 claim. Encoded attachment files are trimmed for brevity:

ISA*00*          *00*          *ZZ*123456789      *ZZ*112233445     *220101*1151*^*00501*0001223344*0*P*:~      <-- ISA13 control number
*112233*X*005010X210~                       <-- GS06 group control number
ST*275*0001*005010X210~                     <-- Beginning of new 275 transaction!
BGN*02*1122334455667788*20220101~           <-- Claim info begins for this transaction
NM1*41*2*REGIONAL PPO NETWORK*****46*123456789~
NM1*1P*2*HAPPY DOCTORS GROUP*****XX*1122334455~    <-- Provider info Loop 1000C w- NPI
N3*200 2nd St Apt 2~
N4*SECOND CITY*IL*22222-2222~
REF*EJ*C1122334455667~           <-- Patient control number (Loop 1000D)
DTP*472*RD8*20200622-20200623~   <-- Claim service date, end of claim info
LX*1~                            <-- First LX 2000A Loop with single encoded attachment
TRN*1*1234567~                   <-- Attachment Control Number (2300 loop PWK06)
DTP*368*D8*20220101~             <-- Describes the date for the full claim
BIN*88487*Mime-version: 1.0      <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=right_hand.jpg

LX*2~                             <-- Second LX 2000A Loop!
TRN*1*1234568~                    <-- Attachment Control Number (2300 loop PWK06)
BIN*447989*Mime-version: 1.0      <-- BIN segment!!
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=right_arm-pictures.pdf

SE*36*0001~                      <-- End of this complete 275 transaction
GE*1*112233~                     <-- GE02 is group control number from GS06
IEA*1*0001223344~                <-- IEA02 completes the Batch 275 submission



Observe that the Submitter ID (the organization submitting the batch 275) is entered in three places: ISA06, GS02, and NM109 of the submitter's NM1 segment. The provider isn't the submitter in this example. ISA06 and GS02 may be the trading partner who acts as the interchange sender. Your Change Healthcare representative can provide you the Trading Partner IDs and Submitter IDs that you need for your submissions.

The 275 transaction ends with the SE segment. The completed batch 275 submission ends with the standard envelope trailers. If the batch includes another 275 transaction, it begins and ends with its own ST/SE transaction header and trailer.

Supporting Multiple Claims

You can have multiple 275 transactions inside your GS/GE functional group.

Each ST segment represents a single 275 transaction to support a single medical claim. To support multiple claims, you use multiple ST/SE envelopes.

Each transaction supported in the batch starts with its own ST segment and ends with an SE segment, forming the innermost envelope in the 275 hierarchy. Instead of showing a very long EDI example, here is a pseudocode outline of what such information would look like:

ISA Envelope (only one for the entire submission)
  GS envelope (only one for the entire submission)
    ST 275 Transaction header #1
      Separate Claim Information (BGN, NM1... )
        2000A Loop LX Segment #1
          TRN Segment...
          BIN Segment
        2000A Loop LX Segment #2
          TRN Segment...
          BIN Segment
    SE Trailer
    ST 275 Transaction Header #2
      Separate Claim Information (BGN, NM1... )
        2000A Loop LX Segment 
          TRN Segment...
          BIN Segment
    SE Trailer
  GE Trailer (only one for the entire submission)
IEA Trailer (only one for the entire submission)
  • ST segment #1 refers to one claim, with one claim reference and two LX segments each containing an attachment.
  • ST segment #2 refers to a different claim, and sends one attachment within an LX loop.

Supporting 837 Service Line Information

As previously noted, 275s support Professional and Institutional claims with two categories of electronic attachments:

  • Claim Supplemental Information (837 Loop 2300)
  • Line Supplemental Information (837 Loop 2400)

The example in the previous section describes claim-level services attachment information. Service lines describe more-detailed parts of a medical claim.

In the following example, the batch 275 submission supports two service line level attachments. The concept is similar to submitting two claim-level attachments, with Loop 2000A REF EDI segments matching each service line in the 275 transaction.

Showing only the two LX loops for this example, a basic EDI structure is as follows:

<Envelope headers and claim information>
LX*1~                         <-- Sequence number (this is the first 2000A loop)
DTP*368*D8*20220117~          <-- Submission sending date
DTP*472*D8*20210921~          <-- Service Line date (DTP01 shows this is for a Line)
REF*6R*25335~                 <-- The service line item control number
REF*CPT*44397**YJ:0490~       <-- Procedure and Revenue codes for the line item
CAT*AE*TX~                    <-- Attachment format code
BIN*42299*Mime-version: 1.0   <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=surgery_notes.pdfJVBERi0xLjcKCjQgMCBvYmoKPDwKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2
LX*2~                          <-- Second service line, second 2000A loop
REF*6R*25336~                  <-- Second service line item control number
REF*CPT*33441**YJ:0490~        <-- Codes for the second item
CAT*AE*MB~                     <-- Different attachment format 
BIN*5948832*Mime-version: 1.0  <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=left-side-pictures.pdf

<Envelope trailers>


The first REF segment in each LX loop provides the service line match (REF*6R*25335), to the correct service line in the 837 claim. This value must match the 837's Loop 2400 (Line Item Control Number), REF segment, elements REF01 and REF02.

The second REF segment defines the medical procedure code (in REF02) for the service that is reported in the 837, and the billing code in REF04 (YJ:0490). It also describes the medical coding type (typically Common Procedural Terminology, or CPT, in REF01), by which the services are being reported. If used, it must match with the SV101-2/SV201-2/SV301-2 compound value in the 837.

The line item may or may not be identified using both the procedure code and a revenue code, so carefully check to determine if the service line item provides the revenue code.

Both reside in the 275's Loop 2000A, unlike the claim-level REF segments for the payer, submitter, provider and patient (1000D).

You can combine claim-level and line-level attachment 2000A loops in a single transaction (ST/SE envelope).


Due to limitations on how batch 275s can be structured for submission, you cannot associate more than one attachment to the same 837 service line. As a workaround, create a PDF combining the attachment content that might otherwise be separately forwarded. Attachment file size limit is 64 MB, which should be sufficient for most applications; contact your Change Healthcare support representative if you need further assistance.



Some standard segments in the 275 2000A loop, such as STC, won't appear in submissions described for this document. You use the STC segment to respond to 277 solicited documentation requests from payers, which are not supported in this Guide.

Payer-Specific Requirements

Some medical insurance payers have specific requirements for supporting batch 275 submissions. Change Healthcare recommends observing requirements from the following payers:


QualLynx requires the Attachment Control Number to match the External Claim Number on the 837 submission.


Providers may submit unsolicited attachments only to claims in prior to adjudication status. Wellcare does not accept electronic 275 attachments for use in appeals, disputes or grievances.

Wellcare also requires the following exact matches from unsolicited 275 submissions to 837 claims:

275/837 Element NameThis 275 Loop/SegmentMatches to 837 Loop/Segment
Control Number
Loop 2000A TRN02

Loop 2300 PWK06

Provider NPI
Loop 1000C NM109

Loop 2010AA NM109

Subscriber IDLoop 1000D NM109

Loop 2010BA NM109

Patient Name

Loop 1000D;
NM103 & NM104

If 837 uses Loop 2010CA,
then match against
2010CA NM103 & NM104;
else 2010BA NM103 & NM104.

Interpreting a 999 Response

You will receive a 999 acknowledgment from Change Healthcare for each 275 submission.

The 999 acknowledges receipt of your 275 submission and lists out the individual 275 transactions contained in the GS functional group from the submission. The example below shows a 999 response to a functional group containing three 275 transactions:

ISA*00*          *00*          *ZZ*133052274      *ZZ*200817213      
TA1*200005001*220106*0851*A*000~      <-- Interchange ack header (**A*000** indicates no errors)
ST*999*0001*005010X231A1~                 <-- Transaction set header
AK1*PI*200005001*005010X210~              <-- Start ack for the submission's functional group
AK2*275*0001*005010X210~                  <-- Refers to first 275 transaction in batch
IK5*A~                                    <-- This one is Accepted
AK2*275*0002*005010X210~                  <-- Refers to second 275 transaction in batch
IK5*A~                                    <-- Also Accepted
AK9*A*0*1*1~                              <-- Functional group response shows Accepted
SE*14*0001~                               <-- Transaction set trailer

The 999 acknowledges reception of the batch 275 submission, and acceptance of both 275 transactions in the batch submission. Its primary value is in letting you know that Change Healthcare received the batch, and is moving it on for further processing.

A significant caveat applies to any 999 you receive. 999s do not contain fully accurate information about possible errors and omissions in the associated 275; you cannot assume you are in the clear and that the attachments are successfully bound to the claim.

If there is more than one 275 transaction in the batch submission, the 999 will have its own mirroring ST segments (inside the GS functional group) listing its acknowledgements.

The AK2 segments shown here are mandatory only if a specific 275 transaction shows errors. The 999 TR3 makes provisions for error reporting, but in practice this rarely if ever happens. A 999 of this type does not necessarily indicate a flawless electronic transmission.

For details on the 999, see the ASC X12 999 Technical Report Type 3.

Change Healthcare Client Checklist

Make sure to get the following information from your Change Healthcare representative:

  • SFTP Login/Password;
  • SSH Secret Pair;
  • Required SFTP configuration security settings;
  • The Change Healthcare Submitter ID (you use this for all your batch 275 submissions, goes in element ISA06 of every batch submission's ISA envelope);
  • Required Trading Partner IDs.

Key Terminology

InboundDirection describing data going from the provider to the payer, through the Change Healthcare clearinghouse.
OutboundDirection describing information going from the payer to the provider, through the Change Healthcare clearinghouse.
SubmissionComplete EDI message that contains at least one transaction to electronically request payment approval for a medical claim, or to provide documentation to support a claim.
UnsolicitedDocuments that you send to the insurance payer without a previous request from the payer. It must have accurate and complete information associating it with the correct service lines in specific medical claims.
AttachmentA document, such as a photograph or a descriptive piece of writing, corroborating performance of medical care. Providers send these documents to insurance companies to help adjudicate and determine payments.
Batch 275 SubmissionA set of one or more 275 transactions containing documents to support one or more medical claims. This document describes how to successfully build a batch 275 submission.
* 275 TransactionThe main unit in a batch 275 submission. It is a unique set of medical documents for a single claim. Defined by an ST/SE envelope. Each document is associated with a service rendered on the claim. Any 275 transaction can support one claim with multiple documents.
HeaderAn EDI statement defining the beginning of an X12 envelope as part of X12's Interchange Control hierarchy. There are three key X12 header types: ISA, GS, and ST.
TrailerAn EDI statement defining the end of an X12 envelope. There are three key trailer types: IEA, GE and SE.

Batch 275 Submissions FAQ

  • Can we submit a Medical Attachment for a claim that was not processed by Change Healthcare?

Yes. Change Healthcare can process your attachment submissions, including batch 275 submissions, without ever processing the medical claim(s) associated with your attachment transactions. If the payer can accept unsolicited attachment transactions, we can support it.

  • What types of file formats are supported by Batch medical attachments?

Change Healthcare supports the following formats for 275 transactions: PDF, TIF, TIFF, JPEG, JPG, PNG

Payers provide varying support for these formats. Consult your Change Healthcare representative to determine which formats your payers can work with.

  • What are the file size or page count limitations for Batch 275 Submissions?

No single BIN segment's contents can exceed 64 MB, so your maximum file size also is 64 MB.

  • What are the differences between Worker's Compensation and Medical Attachments?

Worker's Comp and Medical Attachments have the following differences:

  • Change Healthcare's Medical Network uses Workcomp-EDI as our partner for attachments in Worker's Compensation claims. These claims must be submitted through the Relay Health clearinghouse network, and submitters must be registered with Relay Health to submit them.
  • Medical Attachments transactions utilize the ANSI X12 275 transaction (extensively described in this document) or the Change Healthcare API solution.
  • My payer supports electronic claim submissions but does not support electronic 275 attachment submissions!

You can still submit your 275 transactions or batch 275s. In this case, Change Healthcare will print or fax the attachments with the correct claim information, and send them to the payer.