Standard Companion Guide

Refers to the Implementation Guide

Based on X12 Version 005010X212
Health Care Claim
Status Request and Response
(276/277)

Companion Guide Version Number 5.1

March 13, 2023

Page 1 of 19
CHANGE LOG
Version Release Date Changes

1.0 09/15/2010 Created 276/277 Companion Guide based on version 5010.

Changed Clearinghouse name from Ingenix to OptumInsight; Updated all sections

2.0 09/11/2017
with current information, including hyperlinks and contacts.

Updated Intelligent EDI hyperlink in sections 2.3In and 3.8; Updated hyperlink to
3.0 09/28/2018
EDI 270/271 page online in section 4.1.

Updated Diagram 3.1, Update Diagram 3.2, Updated hyperlink to EDI Transaction
4.0 11/01/2020
Support Form in section 2.3, 3.5, 4.1 and 4.3, Updated Intelligent EDI hyperlink in
sections 2.3 and 3.8.

Updated 1.c Claim Submitted Charge in section 6.1 (276 Request)

5.0 05/28/2021

5.1 03/13/2023 Replace the UnitedHealthcare logo.

Page 2 of 19
PREFACE
This companion guide (CG) to the Technical Report Type 3 (TR3) adopted under Health Insurance Portability and
Accountability Act (HIPAA) clarifies and specifies the data content when exchanging transactions electronically
with UnitedHealthcare. Transactions based on this companion guide used in tandem with the TR3, also called
276/277 Claim Status Request and Response ASC X12N (005010X212), are compliant with both X12 syntax and
related guides. This companion guide is intended to convey information that is within the framework of the TR3
adopted for use under HIPAA. The companion guide is not intended to convey information that in any way
exceeds the requirements or usages of data expressed in the TR3.

Page 3 of 19
 Table of Contents
CHANGE LOG ................................................................................................................................................. 2
PREFACE ........................................................................................................................................................ 3
1. INTRODUCTION ................................................................................................................................. 6
1.1 SCOPE ......................................................................................................................................... 7
1.2 OVERVIEW .................................................................................................................................. 7
1.3 REFERENCE .................................................................................................................................. 7
1.4 ADDITIONAL INFORMATION ........................................................................................................ 7
2. GETTING STARTED ............................................................................................................................. 7
2.1 EXCHANGING TRANSACTIONS WITH UNITEDHEALTHCARE ............................................................ 7
2.2 CLEARINGHOUSE CONNECTION .................................................................................................... 7
2.3 DIRECT CONNECTION ................................................................................................................... 8
3. CONNECTIVITY AND COMMUNICATION PROTOCOLS .......................................................................... 8
3.1 PROCESS FLOW: BATCH CLAIM STATUS REQUEST AND RESPONSE ................................................. 8
3.2 PROCESS FLOW: REAL-TIME ELIGIBILITY INQUIRY AND RESPONSE ................................................. 9
3.3 TRANSMISSION ADMININSTRATIVE PROCEDURES ...................................................................... 10
3.4 RE-TRANSMISSION PROCEDURES ............................................................................................... 10
3.5 COMMUNICATION PROTOCOL SPECIFICATIONS .......................................................................... 10
3.6 PASSWORDS.............................................................................................................................. 10
3.7 SYSTEM AVAILABILITY................................................................................................................ 10
3.8 COSTS TO CONNECT ................................................................................................................... 10
4. CONTACT INFORMATION ................................................................................................................. 11
4.1 EDI SUPPORT ............................................................................................................................. 11
4.2 PROVIDER SERVICES .................................................................................................................. 11
4.3 APPLICABLE WEBSITES/EMAIL.................................................................................................... 11
5. CONTROL SEGMENTS/ENVELOPES .................................................................................................... 11
5.1 ISA-IEA ...................................................................................................................................... 11
5.2 GS-GE ........................................................................................................................................ 12
5.3 ST-SE ......................................................................................................................................... 12
5.4 CONTROL SEGMENT HIERARCHY ................................................................................................ 13
5.5 CONTROL SEGMENT NOTES ....................................................................................................... 13
5.6 FILE DELIMITERS ........................................................................................................................ 13
6. PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS ......................................................................... 13
6.1 276 REQUEST............................................................................................................................. 13

Page 4 of 19
 6.2 277 RESPONSE ........................................................................................................................... 15
7. ACKNOWLEDGEMENTS AND REPORTS .............................................................................................. 15
7.1 REPORT INVENTORY .................................................................................................................. 15
8. TRADING PARTNER AGREEMENTS .................................................................................................... 15
8.1 TRADING PARTNERS .................................................................................................................. 15
9. TRANSACTION SPECIFIC INFORMATION ............................................................................................ 15
9.1 CLAIM STATUS REQUEST AND RESPONSE: 276 (05010X212) ........................................................ 16
10. APPENDECIES................................................................................................................................... 17
10.1 IMPLEMENTATION CHECKLIST .................................................................................................... 17
10.2 FREQUENTLY ASKED QUESTIONS ................................................................................................ 17
10.3 FILE NAMING CONVENTIONS ..................................................................................................... 17
10.4 DEFINITIONS.............................................................................................................................. 18

Page 5 of 19
1. INTRODUCTION

This section describes how Technical Report Type 3 (TR3), also called 276/277 Health Care Claim Status Request
and Response ASC X12N (005010X212), adopted under HIPAA, will be detailed with the use of a table. The tables
contain a row for each segment that UnitedHealth Group has included, in addition to the information contained
in the TR3s. That information can:
1. Limit the repeat of loops, or segments
2. Limit the length of a simple data element
3. Specify a sub-set of the TR3’s internal code listings
4. Clarify the use of loops, segments, composite and simple data elements
5. Any other information tied directly to a loop, segment, and composite or simple data element pertinent
to trading electronically with UnitedHealthcare

In addition to the row for each segment, one or more additional rows are used to describe UnitedHealthcare’s
usage for composite and simple data elements and for any other information. Notes and comments should be
placed at the deepest level of detail. For example, a note about a code value should be placed on a row
specifically for that code value, not in a general note about the segment.

The table below specifies the columns and suggested use of the rows for the detailed description of the
transaction set companion guides. The table contains a row for each segment that UnitedHealthcare has
included, in addition to the information contained in the TR3s.

The following table specifies the columns and suggested use of the rows for the detailed description of the
transaction set companion guides:

Page Loop ID Reference Name Codes Length Notes/Comments

#
45 2100D NM1 Subscriber Name This type of row always exists to indicate that
a new segment has begun. It is always shaded
at 10% and notes or comment about the
segment itself goes in this cell.
57 2100D NM109 Subscriber 2/80 This type of row exists to limit the length of
Primary the specified data element.
Identifier
62 2200D REF Subscriber
Additional
Identification
69 2210D SVC01-01 Product/Service AD, ER, These are the only codes transmitted by
Identification HC, HP, UnitedHealth Group.
Qualifier IV, N4,
NU, WK
Product/Service HC This type of row exists when a note for a
Identification particular code value is required. For example,
Qualifier this note may say that value HC is the default.
Not populating the first 3 columns makes it
clear that the code value belongs to the row
immediately above it.
73 2210D REF

Page 6 of 19
 73 2210D REF01 Reference FJ This row illustrates how to indicate a
Identifier component data element in the Reference
Qualifier column and also how to specify that only one
code value is applicable.

1.1 SCOPE
This document is to be used for the implementation of the TR3 HIPAA 5010 276 Claims Status Request and
277 Response (referred to as Claim Status in the rest of this document) for the purpose of submitting claim
status requests electronically to UnitedHealthcare and to receive claim status responses electronically back
from UnitedHealthcare. This document is to be used as a Companion Guide (CG) to the 276/277 Health
Care Claim Status Request and Response ASC X12 (005010X212) Implementation Guide, also referred to as
Technical Report Type 3 (TR3), not intended to replace the TR3.

1.2 OVERVIEW
This CG will replace, in total, the previous UnitedHealthcare CG versions for Health Care Claim Status Request
and Response and must be used in conjunction with the TR3 instructions. The CG is intended to assist you in
implementing electronic claim status transactions that meet UnitedHealthcare processing standards, by
identifying pertinent structural and data related requirements and recommendations.
Updates to this companion guide will occur periodically and new documents will be posted in the Companion
Guides section of our resource library and distributed to all registered trading partners with reasonable
notice, or a minimum of 30 days, prior to implementation.
In addition, all trading partners will receive an email with a summary of the updates and a link to the new
documents posted online.

1.3 REFERENCE
For more information regarding the ASC X12 Standards for Electronic Data Interchange 276/277 Health Care
Claim Status Request and Response (005010X212) and to purchase copies of the TR3 documents, consult the
Washington Publishing Company website.

1.4 ADDITIONAL INFORMATION

The American National Standards Institute (ANSI) is the coordinator for information on national and
international standards. In 1979 ANSI chartered the Accredited Standards Committee (ASC) X12 to develop
uniform standards for electronic interchange of business transactions and eliminate the problem of non-
standard electronic data communication. The objective of the ASC X12 committee is to develop standards to
facilitate electronic interchange relating to all types of business transactions. The ANSI X12 standards is
recognized by the United States as the standard for North America. Electronic Data Interchange (EDI)
adoption has been proved to reduce the administrative burden on providers.

2. GETTING STARTED

2.1 EXCHANGING TRANSACTIONS WITH UNITEDHEALTHCARE

UnitedHealthcare exchanges transactions with clearinghouses and direct submitters, also referred to as
Trading Partners. Most transactions go through the OptumInsight clearinghouse, formerly Ingenix Health
Information Network (HIN), our managed gateway for EDI transactions.

2.2 CLEARINGHOUSE CONNECTION

Page 7 of 19
 Physicians, facilities and health care professionals should contact their current clearinghouse vendor to
discuss their ability to support the X12 Version 005010X212 276/277 claim status transaction, as well as
associated timeframes, costs, etc. This includes protocols for testing the exchange of transactions with
UnitedHealthcare through your clearinghouse.

2.3 DIRECT CONNECTION

UnitedHealthcare: To set up a new direct connection for real-time or if experience issues with existing
connections, please contact EDI Support by using our EDI Transaction Support Form, sending an email to
supportedi@uhc.com or call us at 800-842-1109.

Optum: Physicians, facilities and health care professionals can submit and receive EDI transactions direct
through Optum using Intelligent EDI (IEDI). For more information, please contact your Optum account
manager. If you do not have an account manager, please contact the Optum sales team at 866-367-9778,
option 3, send an email to IEDIsales@optum.com or visit their website.

3. CONNECTIVITY AND COMMUNICATION PROTOCOLS

3.1 PROCESS FLOW: BATCH CLAIM STATUS REQUEST AND RESPONSE

The response to a batch of claim status transactions will consist of:
1. First level response – TA1 will be generated when errors occur within the envelope.
2. Second level response – 999 Functional Acknowledgement may contain both positive and negative
responses. Positive responses indicates conformance with TR3 guidelines; negative responses
indicates non-compliance with TR3 guidelines.
3. Third level response – A single batch containing 277 responses for each 276 transaction that passes
the compliance check in the second level response. This includes 277 responses with STC errors.

Claim
Claim Status
Status Inquiry
Inquiry

Optum Insight
Provider or
or TA1
Provider’s
Direct Connect UnitedHealthCare
Clearinghouse
TA1 -or- or
999 -or- Optum IEDI
Claim Status 999
Response

Claim
Status
Response

Page 8 of 19
 When a batch of eligibility transactions is received, the individual transactions within the batch are first
checked for format compliance. A 999 Functional Acknowledgement transaction is then created indicating
number of transactions that passed and failed the initial edits. Data segment AK2 identifies the transaction
set and data segment IK5 identifies if the transaction set in AK2 accepted or rejected. AK9 indicates the
number of transaction sets received and accepted.

Transactions that pass envelope validation are then de-batched and processed individually. Each transaction
is sent through another map to validate the individual eligibility transaction. Transactions that fail this
compliance check will generate a 999 with an error message indicating that there was a compliance error.

Transactions that pass the compliance check but fail during the processing phase will generate a 277 response
including a Service Type Code (STC) segment indicating the error reason.

Transactions that pass compliance checks and process successfully will return claim status information in the
277 response.

All of the response transactions including those resulting from the initial edits (999s and 277) from each of
the 276 requests are batched together and sent to the submitter.

3.2 PROCESS FLOW: REAL-TIME ELIGIBILITY INQUIRY AND RESPONSE

The response to a real-time eligibility transaction will consist of:

First level response – TA1 will be generated when errors occur within the outer envelope.
Second level response – 999 will be generated when errors occur during 270 compliance validation.
Third level response – 277 response indicating the claim status in a STC segment or STC segment indicating
the reason for the error.

Claim
Claim Status
Status Inquiry
Inquiry

Optum Insight
Provider or
or TA1
Provider’s
Direct Connect UnitedHealthCare
Clearinghouse
TA1 -or- or
999 -or- Optum IEDI
Claim Status 999
Response

Claim
Status
Response

Each transaction is validated to ensure that the 276 complies with the 005010X212. Transactions which fail
this compliance check will generate a real-time 999 message back to the sender with an error message
indicating that there was a compliance error. Transactions that pass compliance checks but fail during the
processing phase will generate a real-time 277 response transaction including a STC segment indicating the
reason for the error. Transactions that pass compliance checks and do not have errors in a STC segment will
generate a 277 with the STC indicating the status of the claim.

Page 9 of 19
3.3 TRANSMISSION ADMININSTRATIVE PROCEDURES
UnitedHealthcare supports both batch and real-time 276/277 transmissions.

3.4 RE-TRANSMISSION PROCEDURES

Please follow the instructions within the 277 STC segment for information on whether resubmission is
allowed or what data corrections need to be made for a successful response

3.5 COMMUNICATION PROTOCOL SPECIFICATIONS

Clearinghouse Connection: Physicians, facilities and health care professionals should contact their current
clearinghouse for communication protocols with UnitedHealthcare.

Direct Connection
1. UnitedHealthcare: Communication protocols can be obtained by contacting UnitedHealthcare. To set
up a new direct connection for real-time or if experience issues with existing connections, contact EDI
Support by using our EDI Transaction Support Form, sending an email to supportedi@uhc.com or call
us at 800-842-1109.
2. Optum: For communication protocols using IEDI, please contact your Optum account manager. If you
do not have an account manager, please contact the Optum sales team at 866-367-9778, option 3,
send an email to IEDIsales@optum.com or visit their website.

3.6 PASSWORDS
1. Clearinghouse Connection: Physicians, facilities and health care professionals should contact their
current clearinghouse vendor to discuss password policies.
2. CAQH CORE Connectivity: OptumInsight is acting as a CORE connectivity proxy for UnitedHealthcare
Eligibility and Benefit transactions. For information regarding passwords, please contact Optum.

3.7 SYSTEM AVAILABILITY

Normal business hours: Monday - Friday, 5 am to 9 pm CST
Weekend hours: Saturday - Sunday, 5 am to 6 pm CST (exceptions may occur)

UnitedHealthcare systems may be down for general maintenance and upgrades. During these times, our
ability to process incoming 276/277 EDI transactions may be impacted. The codes returned in the STC
segment of the 277 response will instruct the trading partner if any action is required.

In addition, unplanned system outages may also occur occasionally and impact our ability to accept or
immediately process incoming 276 transactions. UnitedHealthcare will send an email communication for
scheduled and unplanned outages.

3.8 COSTS TO CONNECT

Clearinghouse Connection: Physicians, facilities and health care professionals should contact their current
clearinghouse vendor to discuss costs.

Page 10 of 19
 Direct Connection
1. UnitedHealthcare: There is no cost imposed on trading partners by UnitedHealthcare to set up or use a
direct connection.
2. Optum: Using Intelligent EDI (IEDI) to check claim status for UnitedHealthcare is available at no charge. To
verify, contact the Optum sales team at 866-367-9778, option 3, send an email to IEDIsales@optum.com
or visit their website.

4. CONTACT INFORMATION

4.1 EDI SUPPORT

Most questions can be answered by referring to the EDI section of our resource library. View the EDI 276/277
page for information specific to claim status transactions.

If you need assistance with an EDI transaction accepted by UnitedHealthcare, have questions on the format of
the 276/277 or invalid data in the 277 response, please contact EDI Support by using our EDI Transaction
Support Form, sending an email to supportedi@uhc.com or call us at 800-842-1109.

If you have questions related to submitting transactions through a clearinghouse, please contact your
clearinghouse or software vendor directly.

4.2 PROVIDER SERVICES

Provider Services should be contacted at 877-842-3210 instead of EDI Support if you have questions regarding
the details of a member’s benefits. Provider Services is available Monday - Friday, 7 am - 7 pm in the
provider’s time zone.

4.3 APPLICABLE WEBSITES/EMAIL

CAQH CORE: http://www.caqh.org
Companion Guides: https://www.uhcprovider.com/en/resource-library/edi/edi-companion-guides.html
UnitedHealthcare EDI Support: supportedi@uhc.com or EDI Transaction Support Form

UnitedHealthcare EDI Education website: https://www.uhcprovider.com/en/resource-library/edi.html

Optum: https://www.optum.com/

Optum Intelligent EDI - https://www.optum.com/business/solutions/provider/claims-management-

strategy/edi/intelligent-edi.html
Washington Publishing Company - http://www.wpc-edi.com/reference/

5. CONTROL SEGMENTS/ENVELOPES

5.1 ISA-IEA
Transactions transmitted during a session or as a batch are identified by an interchange header segment (ISA)
and trailer segment (IEA) which form the envelope enclosing the transmission. Each ISA marks the beginning
of the transmission (batch) and provides sender and receiver identification.

Page 11 of 19
The table below represents only those fields that UnitedHealthcare requires a specific value in or has
additional guidance on what the value should be. The table does not represent all of the fields necessary for a
successful transaction; the TR3 should be reviewed for that information.

TR3
Loop ID Reference Name Codes Notes/Comments
Page #
ISA Interchange Control
C.3 None ISA
Header
UnitedHealthcare Payer ID
C.5 ISA08 Interchange Receiver ID 87726 -Right pad as needed with
spaces to 15 characters.
Code indicating whether data
C.6 ISA15 Usage Identifier P enclosed is production or
test.

5.2 GS-GE
EDI transactions of a similar nature and destined for one trading partner may be gathered into a functional
group, identified by a functional group header segment (GS) and a functional group trailer segment (GE). Each
GS segment marks the beginning of a functional group. There can be many functional groups within an
interchange envelope. The number of GS/GE functional groups that exist in a transmission may vary.

The below table represents only those fields that UnitedHealthcare requires a specific value in or has
additional guidance on what the value should be. The table does not represent all of the fields necessary for a
successful transaction; the TR3 should be reviewed for that information.

Page # Loop ID Reference Name Codes Notes/Comments

C.7 None GS Functional Group Header Required Header

UnitedHealthcare Payer ID
C.7 GS03 Application Receiver’s Code 87726
Code
Version/Releases/Industry Version expected to be
C.8 GS08 005010X212
Identifier Code received by UnitedHealthcare

5.3 ST-SE
The beginning of each individual transaction is identified using a transaction set header segment (ST). The end
of every transaction is marked by a transaction set trailer segment (SE). For real time transactions, there will
always be one ST and SE combination. A 276 file can only contain 276 transactions.

The below table represents only those fields that UnitedHealthcare requires a specific value in or has
additional guidance on what the value should be. The table does not represent all of the fields necessary for
a successful transaction; the TR3 should be reviewed for that information.

Page # Loop ID Reference Name Codes Notes/Comments

36 None ST Transaction Set Header Required Header

Page 12 of 19
 Implementation
36 ST03 005010X212
Convention Reference

5.4 CONTROL SEGMENT HIERARCHY

ISA - Interchange Control Header segment
GS - Functional Group Header segment
ST - Transaction Set Header segment
First 276 Transaction
SE - Transaction Set Trailer segment
ST - Transaction Set Header segment
Second 276 Transaction
SE - Transaction Set Trailer segment
ST - Transaction Set Header segment
Third 276 Transaction
SE - Transaction Set Trailer segment
GE - Functional Group Trailer segment
IEA - Interchange Control Trailer segment

5.5 CONTROL SEGMENT NOTES

The ISA data segment is a fixed length record and all fields must be supplied. Fields that are not populated
with actual data must be filled with space.
1. The first element separator (byte 4) in the ISA segment defines the element separator to be used
through the entire interchange.
2. The ISA segment terminator (byte 106) defines the segment terminator used throughout the entire
interchange.
3. ISA16 defines the component element

5.6 FILE DELIMITERS

UnitedHealthcare requests that you use the following delimiters on your 270 file. If used as delimiters, these
characters (* : ~ ^ ) must not be submitted within the data content of the transaction sets. Please contact
UnitedHealthcare if there is a need to use a delimiter other than the following:

1. Data Segment: The recommended data segment delimiter is a tilde (~)

2. Data Element: The recommended data element delimiter is an asterisk (*)
3. Component Element: ISA16 defines the component element delimiter is to be used throughout the
entire transaction. The recommended component-element delimiter is a colon (:)
4. Repetition Separator: ISA11 defines the repetition separator to be used throughout the entire
transaction. The recommended repetition separator is a carrot (^)

6. PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS

6.1 276 REQUEST

For batch and real-time 276 requests, submit:
• One claim inquiry within each ST/SE transaction set request
• One occurrence of the 2000A, 2000B, 2000C, 2100C, 2000D, 2200D
• 2000E and 2200E loops per each ST/SE transaction set request

Page 13 of 19
1. Subscriber and Dependent Date of Birth Requirements:
a. The subscriber date of birth is situational in the 276 request. If the dependent data is not
submitted, the 276 request must have the subscriber date of birth in order for the transaction to
process. If the 276 request does not have the subscriber date of birth, the transaction will reject
for the entity’s date of birth. The 277 response will have STC*E0*158*IL. The 276 request will
need to be resubmitted with the subscriber’s date of birth in order for the transaction to
process.
b. The dependent date of birth is required in the 276 request if the dependent loop is submitted. If
the date of birth for the dependent is not submitted in the 276 request, the transaction will
reject for the entity’s date of birth. The 277 response will have STC*E0*158*IL. The 276 request
will need to be resubmitted with the dependents date of birth in order for the transaction to
process.
c. The Claim Submitted Charges are not required in the 276 request. Claim Charges may be utilized if
submitted in the 276 request along with other submitted criteria. If no claims are found with any
of the submitted criteria, the 276 transaction will reject for “claim not found.” The 277 will have
STC*A4. The 276 will need to be corrected and resubmitted for processing.
2. Date Derivation Logic:
a. If Claim Level from and to date(s) are submitted in the 276 request, these are the date(s) that
will be used when searching for claims.
b. If the Claim Level from and to date(s) are not submitted in the 276 request, the date or range of
dates used when searching for claims will be derived from the service line information received
in the 276 request using the following logic:
i. The dates of service on each service line will be reviewed. The earliest date of service will
be used for the “from date” and the latest date of service will be used for the “to date” of
service.
3. No Dates on the 276 Request: If dates are not submitted in the 276 request at the claim or service
line level, the 276 transaction will reject for Dates of Service. The 277 will have STC*E0*158. The 276
will need to be resubmitted with date(s) at the claim or service line level.
4. Future Date on the 276 Request: If the 276 request submitted has a from or to date at the claim or
service line level that is a future date, the 276 transaction will reject for Dates of Service. The 277 will
have STC*E0*158. The 276 will need to be corrected and resubmitted for processing.
5. 276 Request for Claim Date Older Than 18 Months: The system will first calculate the oldest date
that the ‘from’ date can be in order to be considered within 18 months. The current system date and
time stamp will be used to count back 18 months and set the day to the first day of the month. This
system derived date will then be compared to the ‘from’ date. If the ‘from’ date is equal to or later
than the system derived date, then the 276 request is within the 18 month time frame. Otherwise,
the request will reject for Dates of Service. The 277 will have STC*E0*158. The 276 will need to be
corrected and resubmitted for processing.
6. 276 Request Date Range Greater than 31 Days: If the difference between the ‘from’ date and ‘to’
date submitted on the 276 request is greater than 31 days, the system will reduce the range to 31
days by reducing the ‘to’ date.
7. Provider Matching: The provider last name or organization name and the provider first name are not
required to be submitted in the 276 request. If the system finds multiple providers when searching for
claims by using NPI, Tax ID or Service Provider Number only, the 276 transaction will reject for the
entity’s name. The 277 will have STC*D0*125*1P. The 276 will need to be corrected and resubmitted
for processing.
a. The search logic uses a combination of the following data elements: Member ID, Last Name, First
Name and Patient Date of Birth (DOB). It is recommended that the maximum search data
elements are used. This will result in the best chance of finding a member, however, all data

Page 14 of 19
 elements aren’t required. Cascading search logic will go through the criteria supplied and
attempt to find a match. If a match is not found or multiple matches are found, a 277 response
will be sent indicating to the user, if possible, what criteria needs to be supplied to find a match.

The following table describes the data received for each search scenario that will be supported. If the
necessary data elements are not sent to satisfy one of the below scenarios, a 277 with STC*D0*33
‘Subscriber Insured Not Found’ will be returned and a subsequent 276 request with the required additional
data elements will need to be submitted.

SCENARIO Patient/Member ID Last Name First Name Patient DOB

1 X x x x
2 X x x
3 X x x
4 X x
5 X x x
6 x x x

6.2 277 RESPONSE

If the 277 response transaction has an STC*E3, please contact EDI Support for assistance. For research
purposes and quality customer service, our team will require the 276 submitted with the corresponding 277
received. This information will assist us in resolving the issue more expediently.

7. ACKNOWLEDGEMENTS AND REPORTS

7.1 REPORT INVENTORY

None identified at this time.

8. TRADING PARTNER AGREEMENTS

8.1 TRADING PARTNERS

An EDI Trading Partner is defined as any UnitedHealthcare customer (provider, billing service, software
vendor, clearinghouse, employer group, financial institution, etc.) that transmits to, or receives electronic
data from UnitedHealth Group.

Payers have EDI Trading Partner Agreements that accompany the standard implementation guide to ensure
the integrity of the electronic transaction process. The Trading Partner Agreement is related to the electronic
exchange of information, whether the agreement is an entity or a part of a larger agreement, between each
party to the agreement.

For example, a Trading Partner Agreement may specify among other things, the roles and responsibilities of
each party to the agreement in conducting standard transactions.

9. TRANSACTION SPECIFIC INFORMATION

This section describes how TR3’s adopted under HIPAA will be detailed with the use of a table. The tables contain
a row for each segment that UnitedHealth Group has something additional, over and above, the information in
the TR3’s. That information can:
1. Limit the repeat of loops or segments

Page 15 of 19
 2. Limit the length of a simple data element
3. Specify a sub-set of the implementation guide’s internal code listings
4. Clarify the use of loops, segments, composite and simple data elements
5. Any other information tied directly to a loop, segment, and composite or simple data element
pertinent to trading electronically with UnitedHealthcare

In addition to the row for each segment, one or more additional rows are used to describe UnitedHealthcare’s
usage for composite and simple data elements and for any other information. Notes and comments should be
placed at the deepest level of detail. For example, a note about a code value should be placed on a row
specifically for that code value, not in a general note about the segment.

The following table specifies the columns and suggested use of the rows for the detailed description of the
transaction set companion guides. The table contains a row for each segment that UnitedHealthcare has
included, in addition to the information contained in the TR3s.

Page # Loop ID Reference Name Codes Length Notes/Comments

This type of row always exists to indicate
that a new segment has begun. It is always
56 2100D NM1 Subscriber Name
shaded at 10% and notes or comment
about the segment itself goes in this cell.
Subscriber This type of row exists to limit the length of
57 2100D NM109 2/80
Primary Identifier the specified data element.
Subscriber
62 2200D REF Additional
Identification
AD, ER,
Product/Service
HC, HP, These are the only codes transmitted by
69 2210D SVC01-1 Identification
IV, N4, UnitedHealth Group.
Qualifier
NU, WK
This type of row exists when a note for a
particular code value is required. For
Product/Service
example, this note may say that value HC is
Identification HC
the default. Not populating the first 3
Qualifier
columns makes it clear that the code value
belongs to the row immediately above it.
73 2210 REF
This row illustrates how to indicate a
Reference component data element in the Reference
73 2210D REF01 FJ
Identifier Qualifier column and also how to specify that only
one code value is applicable.

9.1 CLAIM STATUS REQUEST AND RESPONSE: 276 (05010X212)

The below table represents only those fields that UnitedHealthcare requires a specific value in or has
additional guidance on what the value should be. The table does not represent all of the fields necessary for a
successful transaction the TR3 should be reviewed for that information.

Page 16 of 19
10. APPENDECIES

10.1 IMPLEMENTATION CHECKLIST

The implementation checklist will vary depending on your choice of connection: Clearinghouse, Direct
Connect or CAQH CORE Connectivity. A basic checklist would be to:

1. Register with trading partner

2. Create and sign contract with trading partner
3. Establish connectivity
4. Send test transactions
5. If testing succeeds, proceed to send production transactions

10.2 FREQUENTLY ASKED QUESTIONS

1. Does this Companion Guide apply to all UnitedHealthcare payers?
No. It’s applicable to UnitedHealthcare Commercial, UnitedHealthcare Community Plan and
UnitedHealthcare Medicare and Retirement.
2. How does UnitedHealthcare support, monitor and communicate expected and unexpected
connectivity outages?
Our systems do have planned outages. We will send an email communication for scheduled and
unplanned outages.
3. If a 276 is successfully transmitted to UnitedHealthcare, are there any situations that would result in
no response being sent back?
No. UnitedHealthcare will always send a response. Even if UnitedHealthcare’s systems are down and
the transaction cannot be processed at the time of receipt, a response detailing the situation will be
returned.

10.3 FILE NAMING CONVENTIONS

Node Description Value

ZipUnzip_ResponseType_<Batch ID>_<Submitter ID>_<DateTimeStamp>.RES

Responses will be sent as either zipped or
unzipped depending on how
ZipUnzip N - Unzipped Z - Zipped
UnitedHealthcare received the inbound
batch file
TA1 – Interchange Acknowledgement 999 –
ResponseType Identifies the file response type
Implementation Acknowledgement
Response file will include the batch number
Batch ID from the inbound batch file specified in ISA13 Value from Inbound File
ISA13
The submitter ID on the inbound
transaction must be equal to ISA06 value in
Submitter ID ISA08 Value from Inbound File
the Interchange Control Header within the
File
Date and time format is in the next column
DateTimeStamp (time is expressed in military format as MMDDYYYYHHMMSS
CDT/CST)

Page 17 of 19
10.4 DEFINITIONS

Term Qualifier Definition

Functional Acknowledgment for HIPAA 837 file. B2B sends the 999 to
999
TSO when an 837 file is received.
The August 2006 ASC X12 standard format, Version 5, Releast 1, Sub-
5010
release 0 (00[5010]).
The acknowledgment is the electronic response (aka 999 or
Acknowledgment
Functional Acknowledgment).
The official designation of the U.S. national standards body for the
ANSI ASC X12
development and maintenance of EDI standards. EDI X12 is a data
ASC X12
format based on ASC X12 standards. It is used to exchange specific
X12
data between two or more trading partners.
An unprecedented nonprofit alliance of health plans and trade
associations and is a catalyst for industry collaboration on initiatives
that simplify healthcare administration. CAQH solutions promote
quality interactions between plans, providers, and other
CAQH
stakeholders. Additionally, their solutions reduce costs and
frustrations associated with healthcare administration, facilitate
administrative healthcare information exchange and encourage
administrative and clinical data integration.
A handbook providing information and instructions on a particular
Companion Guide
EDI transaction.
Electronic Data Interchange is the computer-to- computer exchange
of business or other information between two organizations (trading
EDI
partners). The data may be in a standard or proprietary format. EDI is
also known as electronic commerce.
EDI X12 is governed by standards released by ASC X12 (The
Accredited Standards Committee). Each release contains a set of
message types, such as invoice, purchase order, healthcare claim,
etc. Each message type has a specific transaction number assigned to
it instead of a name, e.g. an invoice is 810, a healthcare claim is 837,
and eligibility a 270. Every new release contains a new version
EDI X12 Standards
number, e.g. 5010, 5030. Major releases start with a new first
and Releases
number, as 5010, while 5030 is considered a minor release. Minor
releases contain few changes or improvements over major releases
which usually require a significant number of modifications. To
translate or validate EDI X12 data, you need to know transaction
number (message numeric name) and the release version number.
Both of those numbers are inside the file.

Page 18 of 19
 The Health Insurance Portability and Accountability Act (HIPAA) of
1996 is a federal law intended to improve the availability and
continuity of health insurance coverage that, among other things,
places limits on exclusions for pre-existing medical conditions,
permits certain individuals to enroll for available group health care
coverage when they lose other health coverage or have a new
dependent, prohibits discrimination in group enrollment based on
HIPAA
health status, provides privacy standards relating to individuals'
personally identifiable claim-related information, guarantees the
availability of health coverage to small employers and the
renewability of health insurance coverage in the small and large
group markets, requires availability of non-group coverage for
certain individuals whose group coverage is terminated and
establishes standards for electronic transmissions.
Protocols Protocols are codes of correct conduct for a given situation.
A qualifier is a word, number or character that modifies or limits the
Qualifier
meaning of another word or group of words or dates.
A string of data elements that contain specific values based on the
Segment loop and data element on the file which is separated into specific
sections.
TPAs are prominent players in the managed care industry and have
the expertise and capability to administer all or a portion of the
claims process. They are normally contracted by a health insurer or
Third Party self-insuring companies to administer services, including claims
Administrator (TPA) administration, premium collection, no enrollment and other
administrative activities. A hospital or provider organization desiring
to set up its own health plan will often outsource certain
responsibilities to a TPA.
A Trading Partner may represent an organization, group of
Trading Partner organizations or some other entity. In most cases, it is simply an
organization or company.
The EDI X12 standard covers a number of requirements for data
structure, separators, control numbers, etc. However, many big
trading partners impose their own rules and requirements which are
usually more strict and regimented, such as specific data format
Trading Partner requirements for some elements and requirements to contain
Requirements specific segments (segments that are not mandatory in EDI X12
standard being made mandatory). Specific trading partner
requirements are usually listed in a Companion Guide document. It is
essential to follow these documents exactly when implementing EDI
systems.
COB Coordination of benefits.
EOB Explanation of benefits.

Page 19 of 19