Optum Batch Attachment Electronic Interchange Companion Guide

December 2022

Table of Contents

Disclosure
Preface
About This Guide

Supported EDI Transactions
Basic Requirements for Batch 275 Submissions
Recommendation
Timing of Submissions to the Payer

Batch 275 Submission Requirements

Attachment File 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
Exclusions & Limitations
Payer-Specific Requirements

Interpreting a 999 Response

Optum Client Checklist
Key Terminology
Batch 275 Submissions FAQ

Disclosure

Optum 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 Optum 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. Optum 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 Optum.

Preface

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 Optum customers and describes aspects of the Optum network environment, use cases, interchange requirements, transaction responses, acknowledgements, and reporting for each of the transaction types specified in this guide as they are related to Optum. This guide also documents specific information for data elements and values required by Optum.

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.

📘

NOTE

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.

About This Guide

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 Optum Guide:

• Repeatedly 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:

Using this document, you can submit Unsolicited attachments of medical documentation to support a medical claim. An Unsolicited attachment means that the contents you are 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.

📘

NOTE

When necessary, Optum 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. Optum translates automatically when needed.

The following diagram provides a basic illustration of the data flows through Optum'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 Optum;
• A standard SFTP application (Optum provides ECG credentials) that supports Secure SFTP;
• An electronic SFTP mailbox assigned by Optum 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 Optum or from the payer.

Contact your Optum sales representative for information about getting started.

Recommendation

📘

NOTE

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.

Optum 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 Optum (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.

📘

NOTE

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 the clearinghouse receives both the 837 claim and the 275 submission at the same time (or if the 275 batch appears first), the clearinghouse 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 Optum batch attachment processes to support claims to any insurance payer, whether or not they are contracted with Optum. It also extends to payers who support submission of electronic 837 claims but that do not support electronic attachment submissions. Optum also supports print and mail/fax processes for any payer when necessary.

The following requirements apply to all batch 275 submission files submitted through Optum:

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

You send each Batch 275 submission to a single payer. Ensure you use the correct Payer ID value for your submission. If necessary, check with your Optum representative to ensure you have the correct Payer ID values. This also applies to payers who do not support electronic attachment submissions.

Associating 837 Claims with Batch 275 Attachments

Several key EDI elements link Batch 275 submissions to 837 medical claims. You separately submit 837 claims and unsolicited batch 275s, so you need certain pieces of information to tie your attachments to the right claims. Here is a quick summary:

• Each 837 claim uses PWK segments in the 2300 or 2400 loops to associate attachments to each medical service/procedure in the claim:
  – The PWK02 element will typically be set to EL for electronic contents, but this will vary by payer. Some will use the FT (File Transfer) setting;
  – The PWK06 element in the 837 identifies the electronic attachment. Your 275 transactions will consistently refer to this value.
• Payer, provider, and patient information Claim date and medical service dates as needed.

A batch 275 submission can contain several 275 transactions. Each 275 transaction is associated with a medical claim, and can contain multiple attachments. A batch submission can carry information for multiple claims.

Attachment File Requirements

Check with your Optum 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 Optum 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
• Each individual attachment requires a set of standard MIME headers. They 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 Optum representative;
• Ensure you use the correct Payer ID value for your submission. If necessary, check with your Optum 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.

📘

NOTE

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 Optum SFTP site, where your file is automatically picked up by Optum and forwarded to the correct health plan.

Optum provides ECG credentials to access the SFTP server. 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 Optum 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 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:

• The 837 Claim information;
• The LX Loops (Loop 2000A of the 275 submission);
• The BIN segments for the attachments.
  • This contains attachment MIME headers;
  • It also contains the encoded attachment file;
• Using ST segments to support multiple claims/transactions.

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:

```edi
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
NX1*1P~
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 Optum 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 Optum 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.

📘

NOTE

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 Optum 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

📘

Note

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:

```javascript
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.

📘

NOTE

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:

```edi

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
AAUFBQgFCAwHBwwMCQkJDA0MDAwMDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N
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.

Carriage returns follow 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

As previously noted, an attachment can be a graphics image in TIF or JPG format or a PDF document file. To create the attachment file for the 275’s BIN segment, you convert the file to Base64 encoding. It changes the file format to be compatible with Optum’s network, while retaining the integrity of the attachment content.
When you are done, copy and paste the raw encoded data from your file into the BIN02 element.

📘

NOTE

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.
• 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.

The complete BIN segment is a key part of the 275 transaction, contained within a Loop 2000A LX segment.

Setting Up LX 2000A segments in a Claim-Level Transaction

📘

NOTE

For multiple documents to support a single claim, the 837 claim must use multiple PWK segments. Each is associated with an attachment file when necessary.

LX segments enable you to send attachments for a claim. Residing in Loop 2000A of the 275 transaction, an LX segment contains a single BIN, with other vital information. The BIN segment contains a single unique document.
The 2000A LX segment’s Assigned Number element (LX01) contains the value defining each attachment loop (attachment #1, Attachment #2, and so on). The process forms a loop concept in which each LX increments by 1 for each attachment, as in LX_1, LX_2… so you can have multiple LX segments within any single 275 transaction.
This feature gives you more flexibility for 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, element PWK06)

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:

```edi
LX*1~                  <-- Increment this value for each loop
TRN*1*1234567~         <-- This refers to the 837 service line for the attachment 
DTP*368*D8*20220101~
CAT*AE*MB~             <-- Describes the content in the BIN segment
EFI*05~
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

JVBERi0xLjcKCjQgMCBvYmoKKElkZW50aXR5KQplbmRvYmoKNSAwIG9iagooQWRvYmUpCmVuZG9i
ago4IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggNTg0ODAKL0xlbmd0aDEg
MTIyNDA4Ci9UeXBlIC9TdHJlYW0KPj4Kc3RyZWFtCnic7LwHfJRV+j/6nPPOTKYkmZopmUzLJJMy...~
```

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

📘

NOTE

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). It is represented at the claim level (Loop 2300), and at the line level (Loop 2400).

Many submitters will find Loop 2300 claim-level attachment inclusion to be sufficient. Some payers may require more-specific attachment content at the service line level, and some 837 claims may have enough complexity that binding attachment submissions to Loop 2400 of the claim is necessary.

Annotated EDI 275 transaction

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:

```edi
ISA*00*          *00*          *ZZ*123456789      *ZZ*112233445     *220101*1151*^*00501*0001223344*0*P*:~      <-- ISA13 control number
GS*PI*123456789*113355779*20220101*1151
*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*PR*2*EXTRA HEALTHY INSURANCE*****PI*9496~
NM1*41*2*REGIONAL PPO NETWORK*****46*123456789~
NM1*1P*2*HAPPY DOCTORS GROUP*****XX*1122334455~    <-- Provider info Loop 1000C w- NPI
NX1*1P~
N3*200 2nd St Apt 2~
N4*SECOND CITY*IL*22222-2222~
NM1*QC*1*PATIENT*HAPPY****MI*123456789~
REF*EJ*C1122334455667~           <-- Patient control number (Loop 1000D)
DTP*368*DB*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
CAT*AE*MB~
EFI*05~
BIN*88487*Mime-version: 1.0      <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=right_hand.jpg

YEuPa3iyLjcKCjQgMCBvYmoKKElkZW50aXR5KQplbmRvYmoKNSAwIG9iagooQWRvYmUpCmVuZG9i
ago4IDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggNTg0ODAKL0xlbmd0aDEg
MTIyNDA4Ci9UeXBlIC9TdHJlYW0KPj4Kc3RyZWFtCnic7LwHfJRV+j/6nPPOTKYkmZopmUzLJJMy~
LX*2~                             <-- Second LX 2000A Loop!
TRN*1*1234568~                    <-- Attachment Control Number (2300 loop PWK06)
DTP*368*D8*20220101~
CAT*AE*MB~
EFI*05~
BIN*447989*Mime-version: 1.0      <-- BIN segment!!
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=right_arm-pictures.pdf

JVBERi0xLjcKCjQgMCBvYmoKPDwKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2
aWNlUkdCCi9GaWx0ZXIgL0RDVERlY29kZQovSGVpZ2h0IDE3OAovTGVuZ3RoIDkzNDIKL1N1YnR5
cGUgL0ltYWdlCi9UeXBlIC9YT2JqZWN0Ci9XaWR0aCA0ODkKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA~
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
```

📘

NOTE

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 Optum 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 embed 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, the following shows the basic flow:

```edi
ISA Envelope (only one for the entire submission)
  GS envelope (only one for the entire submission)
    ST 275 Transaction header #1
      Claim Information (BGN, NM1... )
        2000A Loop LX Segment #1
          TRN Segment...
          BIN Segment
          (Metadata and encoded attachment)
    SE Trailer
    ST 275 Transaction Header #2
       Claim Information (BGN, NM1... )
        2000A Loop LX Segment #1
          TRN Segment...
          BIN Segment
          (Metadata and encoded attachment)
        2000A Loop LX Segment #2
          TRN Segment...
          BIN Segment 
          (Metadata and encoded attachment)
    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 one LX segments.
• ST segment #2 refers to a different claim, and sends attachments within sequential LX segments.

Supporting 837 Service Line Information

📘

NOTE

If you omit the REF segments and the service-line date-of-service (DTP segment, Loop 2400, page 382 of the 837 TR3) for line-level information, but still use the TRN segment to match against the line’s PWK06, you are essentially reporting the line attachment at the claim level. Many submissions do not bother with line-level information for unsolicited attachments. Some payers emphasize line-level information to associate attachments with line procedures due to prior authorization and other requirements.

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 (from the 837’s Line Item Control Numbers, described in the ASC X12 837 TR3, page 403) in the 275 transaction.

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

```edi
<Envelope headers and claim information>
LX*1~                         <-- Sequence number (this is the first 2000A loop)
DTP*368*D8*20220117~          <-- Submission sending date
DTP*368*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
EFI*05~
BIN*42299*Mime-version: 1.0   <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=surgery_notes.pdfJVBERi0xLjcKCjQgMCBvYmoKPDwKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2
aWNlUkdCCi9GaWx0ZXIgL0RDVERlY29kZQovSGVpZ2h0IDE3OAovTGVuZ3RoIDkzNDIKL1N1YnR5
cGUgL0ltYWdlCi9UeXBlIC9YT2JqZWN0Ci9XaWR0aCA0ODkKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA~
LX*2~                          <-- Second service line, second 2000A loop
DTP*368*D8*20220117~
DTP*368*D8*20210922~           <-- Service Line date!          
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 
EFI*05~
BIN*5948832*Mime-version: 1.0  <-- BIN segment
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=left-side-pictures.pdf

JVBERi0xLjcKCjQgMCBvYmoKPDwKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2
aWNlUkdCCi9GaWx0ZXIgL0RDVERlY29kZQovSGVpZ2h0IDE3OAovTGVuZ3RoIDkzNDIKL1N1YnR5
cGUgL0ltYWdlCi9UeXBlIC9YT2JqZWN0Ci9XaWR0aCA0ODkKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYA~
<Envelope trailers>

```

📘

NOTE

If you do not use line-level REF segments in the 2000A loop, you are reporting at the claim level by default.

The Line-level LX iterations also use the TRN segment to refer to the line-level attachment control number in Loop 2400, element PWK06 of the 837 claim. Service line level references are distinguished by the use of two (or even three) REF segments:

• 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.

• A third line-level REF segment must be used when service line procedure codes have modifiers (Page 84, ASC X12 275 TR3).

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

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.

Combining Claim-Level and Line-Level Attachments

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

```edi
ISA Envelope (only one for the entire submission)
  GS envelope (only one for the entire submission)
    ST 275 Transaction header
      Separate Claim Information (BGN, NM1... )
        2000A Loop LX Segment #1 (claim-level)
          TRN Segment...
          DTP 368 Claim Date Segment...
          DTP 368 Service Line Date
          CAT Segment
          BIN Segment
         2000A Loop LX Segment #2 (line-level)
          TRN Segment...
          DTP 368 Segment (claim date)
          DTP 368 Segment (line item service date)
         **REF 6R Segment**
         **REF CPT Segment**
          CAT Segment
          BIN Segment 
  GE Trailer (only one for the entire submission)
IEA Trailer (only one for the entire submission)

This flow example illustrates the key difference between claim-level and line-level attachment submissions: if the REF segments follow the DTP segments, the LX segment is for a service line-level attachment.

Exclusions and Limitations

Due to limitations on batch 275s structures, 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 Optum support representative if you need further assistance.

📘

NOTE

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. Optum recommends observing requirements from the following payers:

Interpreting a 999 Response

You will receive a 999 acknowledgment from Optum 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:

```edi
ISA*00*          *00*          *ZZ*133052274      *ZZ*200817213      
*100101*0000*^*00501*200005001*0*P*>~
TA1*200005001*220106*0851*A*000~      <-- Interchange ack header (**A*000** indicates no errors)
GS*FA*122132871*200817213*20100101*0000*1*X*005010X231A1~
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
GE*1*1~
IEA*1*200005001~
```

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 Optum received the batch, and is moving it forward 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, despite the A*000 report. It does not confirm 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.

Optum Client Checklist

Make sure to get the following information from your Optum representative:

• SFTP Login/Password;
• SSH Secret Pair;
• Required SFTP configuration security settings;
• The Optum Submitter ID (a submitter ID is assigned to any entity submitting healthcare transactions to a payer. Basically, a submitter ID is your account number with Optum.) 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

Batch 275 Submissions FAQ

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

Yes. Optum 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.

File formats supported by Batch medical attachments

Our Attachments Submission API supports the following formats for 275 attachments: JPG, TIF, TIFF, PDF, JPEG, and PNG. Payers provide varying support for these formats. Consult your Optum representative to determine which formats your payers can work with.

Our attachment solution includes workers’ compensation attachments and medical attachments. Any receiver who does not support electronic attachments will receive the documentation through fax or mail.

• 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:

• Optum'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 Optum 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, Optum will print or fax the attachments with the correct claim information, and send them to the payer.