americhoice 837 hipaa companion document v080201 draft 2€¦ · unitedhealthcare arizona...

837 X12N Companion Document & Guide

837 X12N

Companion Document & Guide

UnitedHealthcare Arizona Physicians IPA

Table of Contents

1 Introduction.........................................................................................................................4

1.1 Document Purpose............................................................................................................4 1.2 HIPAA Overview ..............................................................................................................4 1.3 Document Objective .........................................................................................................4 1.4 Contents of this Companion Document........................................................................5

1.4.1 Introduction ...................................................................................................................5 1.4.2 Transaction Overview ..................................................................................................5 1.4.3 Technical Infrastructure ...............................................................................................5 1.4.4 Transaction Standards ..................................................................................................5 1.4.5 Transaction Agreements...............................................................................................5 1.4.6 Transaction Overview ..................................................................................................6

1.5 Related Agreements...........................................................................................................6 1.6 Transmission Schedules ....................................................................................................6

2 Technical Infrastructure and Procedures ..................................................7

3 Communication Methods Available .................................................................7

3.1 Setting up a communication link .....................................................................................7 3.2 Security requirements and procedures, including encryption......................................7 3.3 File naming conventions...................................................................................................7

4 Transaction Standards...............................................................................................8

4.1 General HIPAA transaction standards...........................................................................8 4.2 Testing criteria and procedures........................................................................................8

4.2.1 Test Data Privacy Considerations...............................................................................8 4.2.2 Testing Procedures........................................................................................................9 4.2.3 Acceptance Procedures ................................................................................................9

4.3 Data interchange conventions applicable to the transactions .....................................9 4.3.1 Payer ID Restriction ...................................................................................................10 4.3.2 Provider Identification................................................................................................13 4.3.3 Provider ID Restriction - 837 Segment Usage for 2010AA and 2310B/E ........13 4.3.4 COB where AmeriChoice is a secondary payer ......................................................15 4.3.5 Pre-Paid Encounter Submissions via 837................................................................16

4.4 Procedures for acknowledgment transactions.............................................................17 4.4.1 TA1 Interchange Acknowledgment .........................................................................17 4.4.2 997 Functional Acknowledgment .............................................................................17

4.5 Procedures for handling rejected transmissions, transactions and claims ...............19 4.6 AmeriChoice Level 2 Acknowledgement Data File Layout ......................................20

5 Transaction Agreements ........................................................................................21

5.1 Purpose..............................................................................................................................21 5.2 Agreements .......................................................................................................................21

6 Index .......................................................................................................................................22

UnitedHealthcare Arizona Physicians IPA – 837 Companion Guide

UnitedHealthcare Arizona Physicians IPA – 837 Companion Guide (version 080201) - 4 -

1 Introduction

1.1 Document Purpose Doing business with UnitedHealthcare Arizona Physicians IPA via the X12N formats

Companion Documents are available to electronic trading partners (health plans, program contractors, providers, third party processors, and billing services) to clarify information on HIPAA-compliant electronic interfaces (EDI) with UnitedHealthcare Arizona Physicians IPA. The information contained in this guide will address issues regarding how to exchange data with UnitedHealthcare Arizona Physicians IPA, what information should be included in certain controlling data fields and what the testing and go-live procedures are.

1.2 HIPAA Overview The Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) requires the Department of Health and Human Services to establish national standards for electronic healthcare transactions and national identifiers for providers, health plans and employers. The Act also addresses the security and privacy of health information. The long-term purpose of these standards is to improve the efficiency and effectiveness of the nation’s health care system by encouraging widespread use of standard electronic data interchange.

1.3 Document ObjectiveX12N – Insurance EDI formats defined by ANSI for use in healthcare This Companion Guide will explain how to prepare, maintain and submit a HIPAA compliant transaction to UnitedHealthcare Arizona Physicians IPA. Companion Documents are intended to supplement rather than replace the standard Implementation Guide for each transaction set. This Companion Guide should be used in conjunction with the applicable ANSI Implementation Guide to define information specific to UnitedHealthcare Arizona Physicians IPA and its trading partners. Rules for format, content, and field values can be found in the Implementation Guides. This document describes the technical interface environment with UnitedHealthcare Arizona Physicians IPA, including connectivity requirements and protocols, and electronic interchange procedures. What this companion document will not do: Modify the definition, data condition, or use of any data element or segment in the

standard Implementation Guides. Add any additional data elements or segments to the defined data set. Utilize any code or data values that are not valid in the standard Implementation

Guides. Change the meaning or intent of any implementation specifications in the standard

Implementation Guides.



1.4 Contents of this Companion Document

1.4.1 Introduction This section provides an overview of the purpose and content of the document.

1.4.2 Transaction Overview Section 2.0 provides an overview of the transactions included in this Companion Document including information on: • Related Agreements • Transmission schedules

1.4.3 Technical Infrastructure Section 3.0 provides technical information on transmitting electronic data to and receiving electronic data from UnitedHealthcare Arizona Physicians IPA including information on: • Available Communication Methods • Setting up a communications link • File Transfer Protocol (FTP) procedures • Security requirements and procedures, including encryption • File naming conventions

1.4.4 Transaction Standards Section 4.0 provides information relating to the transactions included in this Companion Document including: • General HIPAA transaction standards • Testing criteria and procedures • Data interchange conventions applicable to the transactions • Procedures for acknowledgment transactions • Procedures for handling rejected transmissions and transactions

1.4.5 Transaction Agreements Section 5.0 provides more specific information relating to the transaction sets supported by this Companion Document including: • A statement of the purpose of transaction agreements between UnitedHealthcare Arizona

Physicians IPA and other covered entities • A detailed Agreement that shows how UnitedHealthcare Arizona Physicians IPA populates

the data elements in the X12N Transactions when UnitedHealthcare Arizona Physicians IPA uses transaction data elements in ways that are not fully described by information in a X12N

Implementation Guide.



1.4.6 Transaction Overview The Implementation Guides for the adopted EDI standards are the ANSI Accredited Standards Committee (ASC) X12N Transaction Set Implementation Guides. Versions of the 4010A addenda adopted by HHS are used in preparation of this document:

ASC X12N 270/271 (004010X092A1)

ASC X12N 276/277 (004010X093A1)

ASC X12N 278 (004010X094A1)

ASC X12N 820 (004010X061A1)

ASC X12N 834 (004010X095A1) ASC X12N 835 (004010X091A1)

ASC X12N 837I (004010X096A1)

ASC X12N 837P (004010X098A1)

ASC X12N 837D (004010X097A1)

NCPDP (5.1 / 1.0)

1.5 Related Agreements Trading Partner Agreements (TPA) for each of the transaction sets are closely related to each of the individual formats. While each format will be different in use, the agreements will all reflect what will be expected by its individual use and what will be expected from the trading partner.

1.6 Transmission Schedules Transmission Schedules will be described in the individual TPA document for each entity. Please refer to that specific document for transmission schedule expectations.



2 Technical Infrastructure and Procedures The primary method of connecting to the UnitedHealthcare Arizona Physicians IPA Central Site Network is by going from the Internet through a SSL/FTP tunnel to the UHC FTP Server. (corpftp.uhc.com) There are multiple methods available to send or receive data with UnitedHealthcare Arizona Physicians IPA.

3 Communication Methods Available Agreements for each of the transaction sets are closely related to the abilities each covered entity may possess to assist them with data communication methods. At this time the following methods are available:

1. Clearinghouse 2. SSL/FTP 3. Direct

3.1 Setting up a communication link To setup a communication link with UnitedHealthcare Arizona Physicians IPA you must first complete and submit the ‘Establish Communications’ request form. After this form is completed and submitted to UnitedHealthcare Arizona Physicians IPA, the necessary information will be sent to you based on the options selected within the request form. For more information, contact EDI Support Services.

3.2 Security requirements and procedures, including encryption To protect PHI data (Protected Health Information) AmeriChoice requires that the submitted data be transmitted via the following methods:

1. Transfer data via a Clearinghouse that requires encryption methods 2. Transfer data via SSL/FTP which inherently protects electronic data. 3. Encrypt the data using the industry standard PGP (Pretty Good Protection) which

applies an adequate level of protection.

3.3 File naming conventions UnitedHealthcare Arizona Physicians IPA follows a system conforming naming convention for files coming into and flowing out of the UnitedHealthcare Arizona Physicians IPA system. To keep and use a standard naming convention for all EDI transactions, the following algorithm should be followed and maintained. Files coming into the UnitedHealthcare Arizona Physicians IPA system will be named using the following template: X12N or Format ID/Plan/Vendor Acronym/Type of file. Example would be: 837PPASPCCLM.DAT for 837P-PA-SPCCLM-.DAT meaning, 837P format, Pennsylvania, Spectrum claims, Data.



Format Plan Vendor File Type

(X12N)

.dat

The actual naming conventions and file names will be determined at the time the Trading Partner Agreements are signed. The above information is given for illustration purposes only.

4 Transaction Standards

4.1 General HIPAA transaction standards HIPAA standards are specified in the Implementation Guides for each mandated transaction and modified by authorized Addenda. The Data Overview Section contains information related to:

• Format and content of interchanges and functional groups. • Format and content of the header, detail and trailer segments. • Code Sets and Values authorized for use in the transaction. • Allowed exceptions to specific transaction requirements.

Size of Transmissions/Batches Transmission sizes are limited based on two factors:

1. Number of Segments/Records allowed by X12N Standards. 2. AmeriChoice file transfer limitations.

HIPAA standards for the maximum file size of each transaction set are specified in the appropriate Implementation Guide or its authorized Addenda. UnitedHealthcare Arizona Physicians IPA file transfer limits are set within the Information Services Division based on the type of data contained within the transaction set. At this time there are no file size limitations.

4.2 Testing criteria and procedures UnitedHealthcare Arizona Physicians IPA has divided HIPAA Transaction and Code Set testing activities into two parts:

• Internal Validation of the Transaction and Code Sets through ClarEDI. • Validation of the Electronic Data Exchange Process with Trading Partners

through our internal data processing/information system.

4.2.1 Test Data Privacy Considerations UnitedHealthcare Arizona Physicians IPA believes that, when possible, use of real-life production data will enhance the overall value of the compliance testing process. However, if covered entities elect to use production data in testing, they must ensure that it remains in compliance with all federal and state privacy regulations. In particular, UnitedHealthcare Arizona Physicians IPA will ensure



data that includes individually identifiable information for use in testing transactions is encrypted or eliminated from tests submitted to the certification testing system unless the testing system meets or exceeds the standards set forth in the final privacy and security rules. UnitedHealthcare Arizona Physicians IPA requires adherence to the same privacy and security standards by its trading partners.

4.2.2 Testing Procedures UnitedHealthcare Arizona Physicians IPA encourages entities to use a third party tool to certify that the entity can produce and accept HIPAA compliant transactions. Success is determined by the ability to pass the five types of compliance tests outlined below prior to commencement of testing with trading partners. The five basic testing categories are:

1. Integrity Testing. This kind of testing validates the basic syntactical integrity of the entity’s EDI file.

2. Implementation Guide-Requirements Testing. This kind of testing involves requirements imposed by the transaction’s HIPAA Implementation Guide, including validation of data element values specified in the Guide.

3. Balancing Testing. Balancing verification requires that summary-level data be numerically consistent with corresponding detail level data, as defined in the transaction’s Implementation Guide.

4. Inter-Segment Situation Testing. Situation testing validates inter-segment situations specified in the Implementation Guide (e.g., for accident claims, an Accident Date must be present).

5. External Code Set Testing. This kind of testing validates code set values for HIPAA mandated codes defined and maintained outside of the Implementation Guides. HCPCS Level I and II Procedure Codes and NDC Drug Codes are examples.

4.2.3 Acceptance Procedures After submitting three test files that pass the ClarEDI audit software the files will be tested through the UnitedHealthcare Arizona Physicians IPA internal processing system. When it has been determined that the data can be processed successfully, a “go-live” date will be scheduled.

4.3 Data interchange conventions applicable to the transactions When transmitting transactions, UnitedHealthcare Arizona Physicians IPA follows standards developed by the Accredited Standards Committee (ASC) of the American National Standards Institute (ANSI). These standards involve Interchange (ISA/IEA) and Functional Group (GS/GE) Segments or “outer envelopes”. All transactions are enclosed in transmission level ISA/IEA envelopes and, within transmissions, functional group level GS/GE envelopes.

The segments and data elements used in outer envelopes are documented in Appendix B1 of theImplementation Guides unless otherwise noted within the Definition/Format columns in Table 4.3.1. Transaction Agreements that specify how individual data elements are populated by UnitedHealthcare Arizona Physicians IPA are shown on the ISA/IEA Table 4.3.1



and GS/GE envelopes that are shown in Table 4.3.2. This document assumes that security considerations involving user identifiers, passwords, and encryption procedures are handled by the UnitedHealthcare Arizona Physicians IPA FTP Server and not through the ISA Segment.

4.3.1 Payer ID Restriction When constructing your data files, UnitedHealthcare Arizona Physicians IPA will expect that you submit one file per Payer Identification Number. Your Interchange Control Structure must reflect this requirement. This will restrict your Interchange Control Structure to one Functional Group Header [GS] per Communication Envelope (transmitted data file). You may transmit multiple files but each file must reflect only those segments that relate to the individual payer.

ISA/IEA Interchange Control Envelope Transaction Agreement Seg ID

Element ID

Element Name Valid Values Definition/Format

ISA Interchange Header ISA ISA01 Authorization

Information Qualifier 00 No Authorization Information present.

ISA ISA02 Authorization Information

Leave blank. Not used at this time.

ISA ISA03 Security Information Qualifier

00 No Security Information present.

ISA ISA04 Security Information Leave blank. Not used at this time.

ISA ISA05 Interchange ID Qualifier ZZ Mutually Defined.

ISA ISA06 Interchange Sender ID

See Appendix C for valid codes. Files from UnitedHealthcare Arizona Physicians IPA will consist of the value: “AC8604770970001”.

ISA ISA07 Interchange ID Qualifier

ZZ Mutually Defined.

ISA ISA08 Interchange Receiver ID

Files sent to UnitedHealthcare Arizona Physicians IPA will consist of the value: “AC8604770970001”.

ISA ISA09 Interchange Date Current date: YYMMDD.

ISA ISA10 Interchange Time Current time: HHMM.

ISA ISA11 Interchange Control Standards Identifier

U U.S. EDI Community of ASC X12, TDCC, AND UCS.

ISA ISA12 Interchange Control Version Number

00401 Draft Standards for Trial Use Approved for Publication by ASC X12 Procedure Review Board through October 1997



ISA/IEA Interchange Control Envelope Transaction Agreement Seg ID

Element ID


ISA Interchange Header ISA ISA13 Interchange Control

Number Unique control number assigned by the sender.

ISA ISA14 Acknowledgement Request

1 Interchange Acknowledgement Request (TA1).

ISA ISA15 Usage Indicator T / P “T” for testing, “P” for production.

ISA ISA16 Component Element Separator

* An “asterisk” (Shift 8 on most keyboards) is the value used by UnitedHealthcare Arizona Physicians IPA for component separation. Segment and element level delimiters are defined by usage in the ISA Segment and do not require separate ISA elements to identify them. Delimiter values, by definition, cannot be used as data, even within free-form messages. The following separator or delimiter values are used by UnitedHealthcare Arizona Physicians IPA: Segment Delimiter – ‘~’ (tilde) Element Delimiter – ‘^’ (carrot) Composite Component Delimiter (ISA16) – ‘*’ (asterisk) These values are used because they are not likely to occur within transaction data. Note: The Pipe (|) character was previously mentioned as an ISA16 Delimiter in earlier versions of this guide.

Seg ID

Element ID


IEA Interchange Trailer IEA IEA01 Number of Included

Functional Groups The number of Functional Groups within

the Interchange Envelope.

IEA IEA02 Interchange Control Number

A control number identical to the value in ISA13.

.



GS/GE Functional Group Envelope Transaction Agreement Seg ID

Element ID


GS Functional Group Header GS GS01 Functional Identifier

Code Code identifying a group of application related

transaction sets (2 character code).

GS GS02 Application Senders Code

Code identifying the party sending the transmission. Same value considerations as ISA06. See Appendix C for valid codes.

GS GS03 Application Receivers Code

Code identifying the party receiving the transmission. Same value considerations as ISA08.

GS GS04 Date The functional group creation date CCYYMMDD.

GS GS05 Time The functional group creation time HHMM.

GS GS06 Group Control Number

Assigned number originated and maintained by the sender.

GS GS07 Responsible Agency Code

X Accredited Standards Committee X12.

GS GS08 Version / Release / Industry Identifier Code

See Implementation Guide for the Standard being submitted. Example: “004010X096A1” (837I – Institutional – Addenda).

Seg ID

Element ID

Element Name

Valid Values Definition/Format

GE Functional Group Trailer GE GE01 Number of

Transaction Sets Included

The number of Transaction Sets within the Functional Group.

GE GE02 Group Control Number

Assigned number originated and maintained by the sender. This value must be identical to the same data element in the associated functional group header, GS06.

Control fields are used within the transaction sets to show ownership for certain areas of information. UnitedHealthcare Arizona Physicians IPA will expect that trading partners will use the providers’ federal tax identification number wherever possible.



4.3.2 Provider Identification When transmitting HIPAA transactions, UnitedHealthcare Arizona Physicians IPA follows standards developed by the Accredited Standards Committee (ASC) of the American National Standards Institute (ANSI). These standards involve Interchange Control (ISA/IEA) and Functional Group (GS/GE) Headers or “outer envelopes”. All Transactions are enclosed in Interchange ISA/IEA envelopes and, within transmissions, Functional Group level GS/GE envelopes. Under NPI (National Provider Identifier) guidelines, proprietary provider identification numbers can no longer be required by payers. Therefore, starting on May 23, 2007, the requirements listed in the following section will only apply for those providers that are not eligible to receive an NPI.

4.3.3 Provider ID Restriction - 837 Segment Usage for 2010AA and 2310B/E

HIPAA transactions require that a trading partner submit the providers’ NPI (National Provider Identifier) and a federal tax identification number as the primary identifiers on a claim. This identifier may not be unique to an individual provider, making it difficult to locate a specific provider in the UnitedHealthcare Arizona Physicians IPA claims processing system. UnitedHealthcare Arizona Physicians IPA will compare the Submitted NPI (NM1/108 XX qualified in the 2010AA and 2310B/E loops) and submitted Tax ID numbers (EI and SY REF values in the 2010AA or 2310B/E loops) against the processing system data. If there is a conflict or no data on file for the identifiers, the claim will be rejected. UnitedHealthcare Arizona Physicians IPA will not use any lower level loops to identify the provider at the service line level. These should not be submitted to UnitedHealthcare Arizona Physicians IPA for that reason. The following information is for those providers unable to submit NPI and Tax ID as the primary identifiers. To ensure our ability to accurately locate the provider within the UnitedHealthcare Arizona Physicians IPA claims processing system you must use the situational secondary REF segment in the Billing Provider 2010AA Loop or the Rendering Physician/Service Facility Loop 2310B/E {depending on which claim format you are sending: Professional (B) and Institutional (E)}. We are allowed to require this situational segment based on Note 1 of the 837 Implementation Guide Loop 2010AA [REF] Segment Notes. Precedence of Loop Usage: The 2010AA Billing Provider is the minimum required Loop. If the 2310B/E REF segment is provided, the identification number will take precedence over the 2010AA REF segment. Further, if the 2310B/2310E Loops are used to support any other data segments, the Secondary Identification REF segment must be supplied in the 2310B/2310E Loops. Note: If the 2310B/E loops are provided, the REF segment must be present. The value will NOT be pulled from the 2010AA REF segment if the 2310B/E loops are provided. If the 2310B/E loop is present and there is no REF segment, the value will NOT be pulled from the 2010AA either. This applies for the NPI and Tax ID REF as well.



Seg ID

Element ID


Billing Provider Secondary Identification - Loop 2010AA REF REF01 Reference Identification

Qualifier G2 Provider Commercial Number * note: This is the UnitedHealthcare Arizona Physicians IPA Provider ID.

REF REF02 Reference Identification Your Provider ID

Provider ID.

Seg ID

Element ID


Rendering Provider/Facility Secondary Identification - Loop 2310B/E REF REF01 Reference Identification

Qualifier G2 Provider Commercial Number * note: This is the UnitedHealthcare Arizona Physicians IPA Provider ID.


Provider ID.

837 Segment Usage for 2010AA and 2310B/E Seg ID

Element ID


REF REF01 Reference Identification Qualifier G2 Provider Commercial Number

Qualifier.


Provider ID.

This change applies to any ASC X12N 837 file transmitted to UnitedHealthcare Arizona Physicians IPA either directly or via a clearinghouse (e.g. WebMD, ProxyMed, MediFax). Should you have any questions concerning the usage of these Loops or Segments within the ASC X12N 837 formats, please call:

UnitedHealthcare Arizona Physicians IPA Support Services800-210-8315 option 1 or e-mail: [email protected]

Note: Provider IDs may differ from one health plan or line of business to another. An ID may contain a base number (or letters and numbers) and a suffix (e.g. – 123456789-00). UnitedHealthcare Arizona Physicians IPA systems always require the use of both the base number and any suffix to identify a Provider. The Provider ID should be supplied without the use of dashes, spaces or other special characters (e.g. – 12345678900).



4.3.4 COB where UnitedHealthcare Arizona Physicians IPA is a secondary payer It is possible to send previous payer claim payment information via an 837 format effective 7/1/2008. The information should follow the normal 837 requirements for Service Line Level (Sections 1.4.2.1.2 Coordination of Benefits — Service Line Level in the 4010 837P Implementation Guide or 1.4.2.1.2 Coordination of Benefits — Service Line Level in the 4010 837I Implementation Guide) with the following limitations:

• The maximum number of other insurances per claim is 10 • There is a maximum of 10 CAS segments per insurance per service line

We also require that a Contractual Obligation and Patient Responsibility segments be submitted for each insurance adjudication per line unless the claim was not covered by the insurer in question. Below is a sample Professional claim with the required information in bold: SBR*S*18*******CI NM1*IL*1*JONES*MICHAEL*A***MI*A99999999 N3*1234 MAIN ST N4*ANYWHERE*AZ*86999 DMG*D8*19700713*F NM1*PR*2*ARIZONA PHYSICIANS IPA INC*****PI*3432 N3*PO BOX 659421 N4*SAN ANTONIO*TX*78265 CLM*XXXX 9999A*130***11>>1*Y*A*Y*Y*B DTP*438*D8*20070101 REF*G1*SEE ATTACHED REF*D9*9999999 HI*BK>36615 NM1*DN*1*SMITH*JOHN****XX*11111111111 REF*1D*777777 NM1*82*1**SMITH*JOHN****XX*11111111111 REF*1G*666666 REF*EI*860000000 REF*G2*666666 SBR*P*18***OT****ZZ AMT*AAE*59.33 AMT*B6*74.16 DMG*D8*20070101*F OI***Y*B**Y NM1*IL*1*JONES*MICHAEL*A***MI*999999999 N3*1234 MAIN ST N4*ANYWHERE*AZ*86999 NM1*PR*2*PERSONAL CARE PLUS*****PI*99999 LX*1 SV1*HC>76519>LT*130*UN*1***1 DTP*472*D8*20070101 CN1*09*74.16 REF*6R*11111111 AMT*T*0 AMT*AAE*74.16 SVD*99999*59.33*HC>76519>LT**1 CAS*CO*45*55.84 CAS*PR*2*14.83 DTP*573*D8*20070110

2330A &B Loops Other Subscriber and Other Payer Segments

2400 Loop Service Line Amount Segments

2320 Loop Other Subscriber Claim Level Payment Segments

2430 Loop Service Line Adjudication Segments



4.3.5 Pre-Paid Encounter Submissions via 837 For those entities submitting Prepaid Encounters to UnitedHealthcare Arizona Physicians IPA in the 837 formats, there are certain elements and usages that are required in addition to the previously mentioned items. They are as follows:

Seg ID

Element ID


BHT BHT06 Reference Identification Qualifier

RP Use RP when the transaction is being sent to an entity (usually not a payer or a normal provider payer transmission intermediary) for purposes other than adjudication of a claim. Such an entity could be a state health data agency which is using the 837 for health data reporting purposes.

Seg ID Element ID Element Name Valid Values

Definition/Format

OTHER SUBSCRIBER INFORMATION - Loop 2320 AMT AMT01 Amount Qualifier Code D Payer Amount Paid

AMT AMT02 Monetary Amount ‘Amount Paid’ Amount Paid by Processor

Seg ID

Element ID


OTHER PAYOR NAME - Loop 2330B DTP DTP01 Claim Adjudication Date 573

DTP DTP02 Date Time Period Format Qualifier

D8 Date Expressed in Format CCYYMMDD

DTP DTP03 Date Time Period ‘CCYYMMDD’ Adjudication or Payment Date



4.4 Procedures for acknowledgment transactions Overview of Acknowledgment Requests Acknowledgment transactions provide senders with confirmation that the transactions have been received and that they were either rejected or accepted at the batch, segment or field level.

The two types of Acknowledgment Transactions are: • Interchange Acknowledgment (TA1) • Functional Acknowledgment (997)

The TA1 Segment acknowledges the electronic transmission without consideration of the individual transactions themselves. The 997 Transaction examines and evaluates the syntax of the electronic transaction at several levels but does not take the meaning of the data that it contains into account. UnitedHealthcare Arizona Physicians IPA expects receivers of Transactions to respond to each electronic transmission that carries them with TA1 and 997 Transactions. The TA1 and 997 are documented in detail within the Appendices B.1 and B.2 of all X12N Implementation Guides. They are frequently generated by translators in response to receipt of electronic transmissions.

4.4.1 TA1 Interchange Acknowledgment Interchange (TA1) acknowledgments allow the receiving trading partner to notify the sending trading partner of the status of interchange headers and trailers. TA1 Segments involve interchanges or transmissions of data and not transactions themselves. Although TA1 Segments technically qualify as transactions, they are transmitted by themselves without outer envelopes.

HIPAA Transactions and Code Sets Final Rule and current Implementation Guides do not mandate the use of the TA1 Acknowledgment but strongly recommend it, particularly when trading partners are initially established. Similar to all Standard Transactions, the TA1 was developed by the ANSI Accredited Standards Committee. It is documented in Appendix B1 of HIPAA Implementation Guides.

4.4.2 997 Functional Acknowledgment The 997 Functional Acknowledgment Transaction is designed to check each functional group in an interchange for syntax errors and return the results to the sending trading partner. A “functional group” consists of one or more transactions of the same kind. For example, if a covered entity receives monthly 834 transactions for 56,000 members, six 834 transactions will make up a functional group: five transactions with 10,000 Member Level Detail Loops each and one with the remaining 6,000. Although each 997 transaction can accept or reject entire functional groups, its edits can be at the transaction, segment, or data element level. Unlike the standalone, fixed format TA1 Segment, the 997 is a full-blown ASC X12 Transaction. It is sent within its own ISA/IEA and GS/GE envelopes and its segments and elements are of variable lengths. The 997 can be sent as



an acknowledgement of receipt for a functional group of transactions or as an indication of syntax errors at the transaction, segment, or data element level. The meaning of syntax errors may be best understood by reviewing the code sets documented in Appendix B.2 of the Implementation Guides. At the data element level, for example, the ten valid values for Element AK403, Data Element Syntax Error Code, include codes for “Mandatory data element missing” and “Invalid character in data element”. Other 997 data elements show the location of the missing or invalid element. What these syntax-level error codes do not take into account are semantic discrepancies, i.e., errors that have to do with the meaning rather than the structure of data elements. Syntactical edits for a claim Service Date, for example, check to see that the date is present, that it is in a valid format, and that its value represents a valid date. Semantic edits performed by the application system ensure that the date is after the member’s date of birth and that it is not a future date.

Characteristics of the 997 transaction include:

• One 997 transaction corresponds to one functional group in an interchange. • 997 transactions are ASC Transaction Sets and are included in the Interchange

Control Structure (envelopes) for transmission. • Many commercially available translators can automatically reconcile the 997

transaction back to a previously transmitted functional group. This process allows the sending trading partner to identify any transactions that have not been acknowledged by the receiving trading partner.

• 997 transactions should not be used to acknowledge the receipt of other 997 transactions.

Details on the format and syntax of the 997 transaction can be found in Appendix B of the applicable Transaction Set’s Standard Implementation Guide.



4.5 Procedures for handling rejected transmissions, transactions and claims

UnitedHealthcare Arizona Physicians IPAcurrently does not support the TA1 and 997 transaction acknowledgement formats for 837 Transactions. This is due to the fact that these transactions do not support the communication of Level 2 Payer Rejects. Level 2 Rejects are claim level rejects that are communicated back to the submitter. These rejects will not be processed and no EOB or other notification will be issued to the provider. It is the responsibility of the submitter to communicate these rejects back to the provider or originating entity for resolution. Rejected claims will need to be corrected and resubmitted by the provider or originating entity in order to receive adjudication or payment. Claims are Level 2 Rejected based on the Provider ID and/or Member ID submitted. The two fields are validated and if either value cannot be matched to the payer records, the claim will be rejected. For assistance in determining possible mapping or EDI issues with submitting Provider ID or Member ID in the correct places, the provider or originating entity should contact their software vendor, clearinghouse or UnitedHealthcare Arizona Physicians IPA EDI Services in that order. In order to communicate the Level 2 rejects, UnitedHealthcare Arizona Physicians IPA will provide an Acknowledgement File for every transmission. All claims submitted within the transmission will be present on the Acknowledgement file. Level 2 rejected claims will be denoted in field ACKS-STATUS-CODE with an “86” or “BF” value. All accepted claims will be denoted in the same field with a “21” value.



4.6 UnitedHealthcare Arizona Physicians IPA Level 2 Acknowledgement Data File Layout Record: ACK-CLAIM-STATUS-RECORD Field Name Field Description Col Len Type Notes ACKS-VENDOR-CRN ACKS-VENDOR-CRN 1 15 AN Carrier Reference Number

ACKS-FILLER ACKS-FILLER 16 1 AN Blank ACKS-RECEIVER-CRN

ACKS-RECEIVER-CRN

17 18 AN UnitedHealthcare Arizona Physicians IPA Xref ID

ACKS-STATUS-CODE

ACKS-STATUS-CODE 35 3 AN 21 – Accepted Claim; 86 – M/I Provider ID; BF – M/I Member ID (86 and BF are rejected claims and will not be processed by carrier)

ACKS-STATUS-DATE ACKS-STATUS-DATE 38 6 Date MMDDYY ACKS-RECEIVER-PHONE

ACKS-RECEIVER-PHONE

44 10 AN

ACKS-GROUP-NUMBER

ACKS-GROUP-NUMBER

54 10 AN

ACKS-AMOUNT-PAID

ACKS-AMOUNT-PAID

64 8 UI

ACKS-PAYEE-CODE ACKS-PAYEE-CODE 72 1 AN ACKS-ACTION-CODE

ACKS-ACTION-CODE 73 1 AN

ACKS-SERVICE-LINE ACKS-SERVICE-LINE 74 6 AN ACKS-VENDOR-SYSTEM

ACKS-VENDOR-SYSTEM

80 1 AN M – Medical (Professional); H – Hospital (Institutional)

Record: ACK-HEADER-RECORD

Field Name Field Description Col Len Type Notes ACKH-LITERAL ACKH-LITERAL 1 12 AN ACKH-RECEIVER-ID ACKH-RECEIVER-ID 13 5 AN ACKH-CREATE-DATE ACKH-CREATE-DATE 18 6 Date MMDDYY ACKH-RECEIVER-SUB ACKH-RECEIVER-SUB 24 4 AN ACKH-MESSAGE-TABLE ACKH-MESSAGE-TABLE 28 2 AN ACKH-FILLER ACKH-FILLER 30 48 AN ACKH-VERSION-CODE ACKH-VERSION-CODE 78 3 AN Record: ACK-TRAILER-RECORD

Field Name Field Description Col Len Type Notes ACKT-LITERAL ACKT-LITERAL 1 12 AN ACKT-RECEIVER-ID ACKT-RECEIVER-ID 13 5 AN ACKT-CREATE-DATE ACKT-CREATE-DATE 18 6 Date MMDDYY ACKT-RECORD-COUNT ACKT-RECORD-COUNT 24 7 UI ACKT-TPO-COUNT ACKT-TPO-COUNT 31 7 UI ACKT-FILLER ACKT-FILLER 38 43 AN



5 Transaction Agreements

5.1 Purpose Transaction specifications are designed, in combination with the X12N Implementation Guides, to identify data to be transmitted between UnitedHealthcare Arizona Physicians IPA trading partners and to specify its type and format. Data structures that are fully covered by the X12N Implementation Guide are not mentioned in this section. Only transaction data with submission requirements specific to UnitedHealthcare Arizona Physicians IPA is included.

5.2 Agreements Appendix A – Trading Partner Agreement

Appendix B – Sender and Receiver Code Standards



6 IndexA Acceptance Procedures, 8 B Billing Provider Secondary ID Loop 2010AA map, 13 C Communication Methods Available, 5 COB where UnitedHealthcare Arizona Physicians IPA is secondary payer, 15 D Data interchange conventions, 9 Document Objective, 1 F 997 Functional Acknowledgment, 14 File naming conventions, 6 G General HIPAA transaction standards, 7 GS/GE Functional Group Envelope, 11 Table 4.3.2 GS/GE control fields., 12 I Interchange (TA1) acknowledgments, 14 Introduction, 2 ISA/IEA Interchange Control Envelope, 9 Table 4.3.1 ISA/IEA control fields., 11 P Payer ID Restriction, 9 Procedures for acknowledgment transactions, 14 Procedures for handling rejected transmissions and transactions, 16 R Related Agreements, 4 S Security requirements and procedures, including encryption, 6 Setting up a communication link, 5 Size of Transmissions/Batches, 7 SSL/FTP Procedures, 5 T Technical Infrastructure, 2 Technical Infrastructure and Procedures, 5 Test Data Privacy Considerations, 8 Testing criteria and procedures, 7 Testing Procedures, 8 Transaction Agreements, 3, 17 Transaction Overview, 2 Transaction Standards, 3 Transmission Schedules, 4