Availity® Health Information Network · intended to supplement, not replace, the standard HIPAA...

AVAILITY HEALTH INFORMATION NETWORK EDI COMPANION GUIDE

Availity® HealthInformation NetworkBatch Electronic Data Interchange (EDI)Standard Companion Guide

Refers to the Implementation Guides Basedon ASC X12 version 005010

October 2020

October 2020 005010


Disclosure StatementAvaility provides the information in this document for education and awareness use only. While Availitybelieves all information in this document to be correct at the time of writing, this document is intendedfor educational purposes only and does not purport to provide legal advice. If you require legal advice,you should consult with an attorney. The information provided here is for reference use only and does notconstitute the rendering of legal, financial, or other professional advice or recommendations by Availity.

The listing of an organization in this document does not imply any sort of endorsement, and Availity takesno responsibility for the third-party products, tools, and Internet sites listed. The existence of a link ororganizational reference in any of the following materials should not be assumed as an endorsement byAvaility.

October 2020 005010 | of 105© Availity, LLC, all rights reserved | Confidential and proprietary.


PrefaceRules for format, content, and data element values are listed in the HIPAA Technical Reports Type 3(TR3s) for submitting 5010 HIPAA transactions. These guides are available on the Washington PublishingCompany website.

This Availity EDI Companion Guide supplements the HIPAA TR3s and describes the Availity HealthInformation Network environment, interchange requirements, transaction responses, acknowledgements,and reporting for each of the transactions specified in this guide as related to Availity. This guide alsoprovides specific information for data elements and values required by Availity.

Important: As defined in the HIPAA TR3s, documents like this Availity EDI Companion Guide areintended to supplement, not replace, the standard HIPAA TR3 for each transaction set. Information in thisguide is not intended to modify the definition, data condition, or use of any data element or segment inthe standard TR3s. It is also not intended to add any additional data elements or segments to the defineddata set. This guide does not utilize any code or data values that are not valid in the standard TR3s. Italso does not change the meaning or intent of any implementation specifications in the standard TR3s.


https://webstore.ansi.org/sdo/wpc

https://webstore.ansi.org/sdo/wpc


Note:

This page is intentionally left blank.


Table of contents

1 Introduction.................................................................................................................................................7

Scope.........................................................................................................................................................7

Overview....................................................................................................................................................7

Benefits......................................................................................................................................................7

Supported EDI transactions...................................................................................................................... 8

2 Getting started........................................................................................................................................... 9

Trading Partner Registration.....................................................................................................................9

3 Availity trading partner QA testing.......................................................................................................... 10

4 Connectivity with the payer/communications.......................................................................................... 11

EDI file submission methods.................................................................................................................. 11

EDI transactions through FTP................................................................................................................ 12

EDI transactions through Availity Portal................................................................................................. 23

Set up EDI reporting preferences...........................................................................................................31

Restore archived files............................................................................................................................. 42

Tips for successful batch file submissions............................................................................................. 45

System status, scheduled maintenance, and cut-off times.................................................................... 47

Confidentiality and access, transaction platforms and deletion of transactions..................................... 48

Transaction response aggregation..........................................................................................................49

5 Contact information..................................................................................................................................50

Availity Client Services............................................................................................................................50

6 Control segments/envelopes................................................................................................................... 51

Interchange Control Header (ISA) and Interchange Control Trailer (IEA) segments..............................51


Functional Group Header (GS) and Functional Group Trailer (GE) segments.......................................55

Submitter (1000A) and Receiver (1000B) loops.................................................................................... 58

7 CAQH CORE Phase II connectivity........................................................................................................ 59

8 Acknowledgements and/or reports.......................................................................................................... 61

EDI response files by transaction...........................................................................................................63

Response file and ERA file naming conventions................................................................................... 65

Notification file.........................................................................................................................................73

File acknowledgement (ACK)................................................................................................................. 75

Interchange acknowledgement............................................................................................................... 76

Implementation acknowledgement..........................................................................................................78

Immediate batch response......................................................................................................................82

Electronic batch report............................................................................................................................89

Delayed payer report.............................................................................................................................. 97

Health care services review (278ebr) summary text report..................................................................102

Proprietary payer report........................................................................................................................105



Introduction

ScopeThe purpose of the Availity Health Information Network EDI Guide (Availity EDI Guide, for short) is tocommunicate Availity-specific requirements and other information that supplements requirements andinformation already provided in standard EDI and HIPAA communications.

OverviewAvaility, LLC., a leader in EDI healthcare technology, offers a full suite of EDI health information exchangeservices through a single web connection to the Availity® Health Information Network. In addition tooffering an extensive array of real-time EDI transactions, we also provide near real-time processing ofbatch EDI transactions. The Availity® Health Information Network is your one stop on the web for secureconnectivity and electronic access to an extensive list of commercial insurance payers.

The Availity® Health Information Network is operationally HIPAA compliant, accepting and processing ina secure environment all American National Standards Institute (ANSI) Accredited Standards Committee(ASC) X12N standard transactions mandated by the Health Insurance Portability and Accountability Act(HIPAA). Availity edits batches of transactions for X12N syntax compliance, and then splits the batchesinto the lowest transaction level possible before applying HIPAA-semantic validation rules. Depending onthe payer, Availity might also apply payer-specific edits to transactions that pass HIPAA syntax validationbefore routing the transactions to the designated payer.

Using the Availity® Health Information Network file transfer features, users can send all files and retrieveresponses through one interface.

BenefitsAs an Availity user, you will realize the following benefits:

• Electronic access to commercial and government insurance payers

• The ability to submit transactions destined for multiple payers in a single batch

• Reduced administrative work and expense

• Reduced postage and material expense

• Ability to submit transactions twenty-four hours a day, seven days a week (except during scheduledmaintenance times)

• Acknowledgement of receipt for each transmitted file

• Increased accuracy of data and reduced risk of duplication

• Increased productivity

• Improved payment cycle and reduced appeals

• Compliance with HIPAA mandates for electronic transactions



Supported EDI transactionsAvaility is operationally HIPAA compliant, securely accepting and processing a number of X12Ntransactions mandated by the Health Insurance Portability and Accountability Act (HIPAA). The tablebelow provides information about the ANSI ASC X12N health care electronic transactions adopted for useby the HIPAA regulations, and supported by the Availity Health Information Network.

Supported transaction formats

Format Version supported Transaction type Optimal batch file

ASC X12N 837 005010X223A2 Institutional Claims 5,000 claims or 4megabytes

ASC X12N 837 005010X222A1 Professional Claims 5,000 claims or 4megabytes

ASC X12N 837 005010X224A2 Dental Claims 5,000 claims or 4megabytes

ASC X12N 270/271 005010X279A1 Health Care BenefitInquiry/Response(Eligibility and Benefits)

4 megabytes

ASC X12N 276/277 005010X212 Health Care ClaimStatus Request/Response

4 megabytes

ASC X12N 278 005010X217 Health Care ServicesRequest (Authorizationand Referral) forReview/Response

4 megabytes

ASC X12N 278 005010X216 Health Care ServicesReview Notification andAcknowledgement

4 megabytes

ASC X12N 835 005010X221A1 Health Care ClaimPayment/Advice (ERA)

4 megabytes1

1 Files over 12 megabytes with large checks might not be validated.



Getting started

Trading Partner RegistrationTo start submitting transactions to the Availity Health Information Network, the Availity administrator foryour organization must first register the organization with Availity by following these steps:

1. Go to www.availity.com and click REGISTER.

Note: The registration must be completed by someone from your business with the authority toauthorize the Availity Organization Agreement.

2. Complete the online registration for your type of organization. The process involves providingdemographic information about your organization and choosing a user ID for the administrator. At theend of the registration process, you will electronically agree to the Organization Access Agreement,which you can print for your records.

Learn More: Learn about Availity Portal registration

When we have processed the application, we send a confirmation by email to the administrator. The firsttime you log in to Availity Portal, the system prompts you to agree to the disclaimer, set up your securityquestions, change your password, and verify your email.

Once the administrator is able to log in to Availity Portal, they can set up authorized personnel in the officeas Availity Portal users. Each user must have a unique user ID and password. Availity does not allowusers to share login credentials.


http://www.availity.com

https://apps.availity.com/availity/Demos/Registration/index.htm


Availity trading partner QA testingAvaility gives you the option of setting up an account in our QA environment so that you can dointegration testing with Availity before you submit any real transactions. Integration testing ensures thatyour translated HIPAA ASC X12N transactions can pass HIPAA standards validation and any applicablepayer-specific edits that Availity performs on the payer's behalf.

Integration testing is coordinated through Availity Client Services (ACS) at no charge to thesubmitter. When you're ready to start testing, please call an Availity Client Services representative at1.800.AVAILITY (282.4548) to set up a test account. ACS will send your request to our implementationsarea and an implementation analyst will contact you to facilitate your Availity implementation.

Note:

• End-to-end testing requires coordination with the payer, and not all payers support end to end testing.If you want end-to-end testing, contact Availity Client Services.

• Availity processes all transactions submitted to the QA environment as test transactions. AlthoughAvaility might forward test transactions to the payer's test environment, the payer does not processthem for payment.



Connectivity with the payer/communications

EDI file submission methodsAvaility provides the following modes for submitting batch files of EDI transactions.

Submit transaction files through FTP

If you work with a practice management system, health information system, or other automated systemthat supports an FTP connection, you can securely upload batch files of X12 EDI transactions to theAvaility FTP site where they are automatically picked up by Availity and submitted to the appropriatehealth plans.

Submit transaction files through Availity Portal

If you have batch files of X12 EDI transactions that you need to process and you don't have access to anFTP connection, you can manually upload the batch files through Availity Portal.

You can choose to always submit your batch files through one mode, or you can submit some batch filesthrough one mode and some through the other mode. If you work with a vendor who has provided youwith an EDI transactions system, such as a practice management system (PMS), hospital informationsystem (HIS), or revenue cycle management system, consult with your vendor to determine how you'llsubmit batch files to Availity.

• Availity partners with many vendors. If you already work with a vendor, you can check their certificationstatus from the Technology Company Partners List.

• If you work with a vendor, follow their instructions for building and submitting batch files.

• If you are a provider who has registered to send Medicare or Medicaid claims through Availity, youmust configure your PMS, HIS, or other EDI system with the correct payer IDs and billing provider IDbefore you can send Medicare or Medicaid EDI claims through Availity. You might need to contact thevendor of your system for assistance with this process.

• Florida providers must register with Florida Medicaid prior to registering to send Medicaid claimsthrough Availity.

Note: If you want to submit real-time (B2B) transactions through Availity's Simple Object Access Protocol(SOAP) Web service, you'll need to contact Availity Client Services to request a B2B setup.


http://www.availity.com/documents/technology_companies_list.pdf


EDI transactions through FTP

Setup steps for EDI through FTP

Getting set up to submit batch files of EDI transactions to Availity through FTP involves the followingsteps, some of which you might have already completed. The lighter-colored tasks, such as integrationtesting, are optional.

1. Register with Availity - If you haven't already registered your organization with Availity, go towww.availity.com and click REGISTER.


2. Integration testing - Availity gives you the option of doing integration testing in our QA environmentbefore you submit any real transactions. See Integration testing through FTP on page 13 for details.

3. Create your Availity FTP account - See Create an Availity FTP account on page 15 for details.

4. Configure your FTP client - See Configure an FTP client on page 17 for details.

5. Set up your EDI reporting preferences - Availity's batch EDI processing generates response filesfor each batch file that you submit. The administrator for an organization can set reporting preferencesthat specify which response files are generated. See Set up EDI reporting preferences on page 31for details.

6. Enroll for transactions - You might need to enroll for some transactions (such as claim submission)for particular health plans that you submit to. To determine if any of the health plans that you submitto require enrollments, see the Availity payer list. You can also enroll (if required) to have electronicremittance advice files (also known as ERAs and 835s) delivered to your Availity mailbox. Electronicremittance advice files display payment information from all claims, whether submitted electronicallyor by paper. See the Availity payer list to determine if enrollment for ERAs is required for a particularhealth plan.

Note: If your ERAs are already delivered to Availity for the health plans that you submit claims to, youcan skip the ERA transaction enrollment process.

7. Set up your Availity Portal users - If other people in your organization need access to Availity Portal,such as to view remittance advice information, you'll need to create an Availity Portal account for eachsuch person. Log in to Availity Portal at https://apps.availity.com, click your name or the avatar icon inthe Availity Portal menu, and then click Add User.

Tip: Have a lot of users? On the Add Users page, click the option to upload users in a spreadsheetin .csv format.



https://apps.availity.com/public-web/payerlist-ui/payerlist-ui/#/


https://apps.availity.com


Integration testing through FTP

Integration testing is coordinated through Availity Client Services at no charge to the submitter. Onceyou've received the login credentials for your QA account from Availity Client Services, you'll need tocomplete the following two setup steps:

1. Create an Availity FTP account in QA on page 13

2. Configure an FTP client for QA on page 14

The process for uploading batches of transaction files to the Availity FTP site, viewing response files,and setting up which response files you receive is exactly the same in the QA environment as it is in theproduction environment.

Create an Availity FTP account in QA

To do integration testing through FTP, you need to create an Availity FTP account in the Availity QAenvironment. Once you've created the FTP account, you'll be able to access your organization's mailboxin the QA environment, allowing you to submit test transactions and retrieve response files.

Important: Availity FTP account administration is limited to certain roles within Availity Portal. If you havethe appropriate permissions, you'll be able to follow the steps below. If you don't have the appropriatepermissions, look up your administrators by clicking your name or the avatar icon in the Availity Portalmenu, and then click My Administrators. Ask an administrator to follow the instructions below to createan FTP account for your organization.

To create an FTP account in the QA environment, follow these steps:

1. Log in to the Availity QA environment at https://qa-apps.availity.com.

2. In the Availity Portal menu, click Claims & Payments > FTP and EDI Connection Services, and thenclick Manage Your FTP Mailbox on the FTP and EDI Connection Services page.

Note: You can also access the FTP and EDI Connection Services page from the My AccountDashboard tab on the Home page.

3. On the Manage Your FTP Mailbox page, select the Organization.


https://qa-apps.availity.com


4. Enter a username and password for the new FTP account, confirm the password, and then clickCreate Account.

Configure an FTP client for QA

Once you've created your Availity FTP account in the QA environment, you'll need to configure your FTPclient (software that allows you to send files through FTP) to connect to the Availity QA FTP site.

1. Launch or open your FTP client software.

2. Enter the following address in the server's host field: qa-ftp.availity.com

3. Enter your Availity QA FTP account username and password.

4. Enter the port number (Port 9922 is usually used for SFTP).

5. Select the appropriate option in your client software for Secure File Transfer Protocol (SFTP), ifavailable and/or applicable. To ensure security, we recommend using the Secure File TransferProtocol (SFTP).

6. Click Connect or press Enter to connect to the server.

If you're prompted to enter a username and password, enter the same Availity QA FTP username andpassword that you entered in your FTP client.

Note: As an alternative to using an FTP client to connect to the Availity FTP site in the QA environment,you can access the QA FTP site by entering the following URL into a browser and then entering your FTPuser name and password: https://qa-ftp.availity.com.


https://qa-ftp.availity.com


Set up FTP for the production environment

Once you've completed any testing you wanted to do in our QA environment, you're ready to create anFTP account in the production environment and start submitting real transactions through the Availity FTPsite.

Create an Availity FTP account

To submit batch files of EDI transactions to Availity through FTP, you need to create an Availity FTPaccount (also referred to as your FTP or SFTP mailbox) in the production environment. Once you'vecreated the FTP account, you'll be able to access your organization's mailbox in the productionenvironment, allowing you to submit transactions and retrieve response files.

• If you requested an Availity SFTP mailbox during registration and completed the associated activation,then skip this task since you've already created your Availity FTP account. If you'd like to change thepassword you were given for your Availity FTP account, log in to Availity Portal and navigate to Claims& Payments > FTP and EDI Connection Services > Manage Your FTP Mailbox.

• Important: Availity FTP account administration is limited to certain roles within Availity Portal. Ifyou have the appropriate permissions, you'll be able to follow the steps below. If you don't have theappropriate permissions, look up your administrators by clicking your name or the avatar icon in theAvaility Portal menu, and then click My Administrators. Ask an administrator to follow the instructionsbelow to create an FTP account for your organization.

To create an FTP account in the production environment, follow these steps:

1. Log in to Availity Portal at https://apps.availity.com.


Tip: You can also access the FTP and EDI Connection Services page from the My AccountDashboard tab on the Home page.

3. On the Manage Your FTP Mailbox page, select the Organization.




4. Enter a username and password for the new FTP account, confirm the password, and then clickCreate Account.

Important: Make a note of these account credentials.

Once you've created your Availity FTP account, you'll want to configure your FTP client with your newaccount credentials.



Configure an FTP client

Once you've created your Availity FTP account in the production environment, you'll need to configureyour FTP client (software that allows you to send files through FTP) to connect to the Availity FTP site.

Note: As an alternative to using an FTP client to connect to the Availity FTP site, you can accessthe FTP site by entering the following URL into a browser and then entering your FTP user name andpassword: https://ftp.availity.com. If you choose this alternative method, you can skip this task, but you'llhave to enter your FTP user name and password each time you access the Availity FTP site.

1. Launch or open your FTP client software.

2. Create a new entry (in your FTP client) for accessing the Availity FTP site, and use the table below tospecify the fields for the new entry.

FTP client settings

Field Value

Host ftp.availity.com

Port 9922 (typically used for SFTP)

Protocol or server type Select the appropriate option in your FTP clientsoftware for Secure File Transfer Protocol(SFTP), if available and/or applicable. Forexample, SFTP - SSH File Transfer Protocol.

Logon type If there is an option for the logon type, selectnormal.

User The user name for your Availity FTP account.

Password The password for your Availity FTP account.

3. Click Connect or press Enter to connect to the server. If you're prompted to enter a user name andpassword, enter the same Availity FTP user name and password that you entered in your FTP client.


https://ftp.availity.com


Change the password for an Availity FTP account

Important: Availity FTP account administration is limited to certain roles within Availity Portal. If you havethe appropriate permissions, you'll be able to follow the steps below. If you don't have the appropriatepermissions, look up your administrators by clicking your name or the avatar icon in the Availity Portalmenu, and then click My Administrators. Ask an administrator to follow the instructions below to createan FTP account for your organization.

To change the password for an Availity FTP account, follow these steps:

1. Log in to Availity Portal at https://apps.availity.com.

Note: If you're changing the password for an FTP account in the QA environment, then log in to theQA environment at https://qa-apps.availity.com and complete the following steps.


3. Enter and confirm the new password, and then click Change Password.

Whenever you change the password on your Availity FTP account, you'll need to update your FTP clientwith the new password.





Submit transaction files via FTP

You can upload your batch files via an FTP client (software that allows you to send files through FTP), orby connecting to Availity's FTP site through a web browser.

Submit batch files via an FTP clientTo submit batch files via an FTP client, follow these steps:

1. Connect to the Availity FTP site through your FTP client.

2. Once you're connected, click the SendFiles folder on the remote site (i.e., the Availity FTP site).

3. Add the files that you want to submit to the SendFiles folder. Availity will then process the files thatyou added.

Submit batch files via FTP through a browserTo submit batch files by connecting to the Availity FTP site through a browser, follow these steps:

1. Enter the following URL in a browser, and then enter your FTP user name and password whenprompted: https://ftp.availity.com.

Note: If you're connecting to the Availity FTP site in the QA environment through a browser, use thefollowing URL, and then enter your QA FTP user name and password: https://qa-ftp.availity.com.

2. On the Availity FTP site, click SendFiles.





3. Click Choose Files, select the file that you want to submit (upload), and then click Open.

4. Verify that the file displayed to the right of the Choose Files button is the file you want, and then clickUpload File. Availity will then process the file that you uploaded.

ResultsAvaility returns a notification file to your SendFiles folder indicating whether a batch file was accepted forprocessing. For details, see the topic on the Notification file on page 73.

Important: Availity removes and archives the notification files from the SendFiles folder each night,whether or not they've been downloaded.



Download response files via FTP

Availity's batch EDI processing generates response files for each batch file that you submit. When you'resubmitting batch files through the Availity FTP site, you'll want to download all response files on a regularbasis to track the transactions that you submitted. Your administrator can specify which responses youreceive.

Response files include Acknowledgements, Immediate Batch Reports, Electronic Batch Reports, andDelayed Payer Reports.

• Acknowledgements identify file-level issues.

• Immediate Batch Reports, Electronic Batch Reports, and Delayed Payer Reports identify claim-levelissues. They contain the information needed to correct and resubmit transactions.

And if you elected to receive electronic remittance advice files (also known as ERAs and 835 files)through the Availity Health Information Network, you'll retrieve those files from the same location as yourresponse files.

To download your response files, follow these steps:

1. Connect to the Availity FTP site through your FTP client or through a browser (by navigating to https://ftp.availity.com).

Note: If you're connecting to the Availity FTP site in the QA environment through a browser, use thefollowing URL, and then enter your QA FTP user name and password: https://qa-ftp.availity.com.

2. Once you're connected, click the ReceiveFiles folder on the remote site (i.e., the Availity FTP site).

3. Use the functions in your FTP client or browser (if that's how you connected) to download files fromthe ReceiveFiles folder. For descriptions of the types of response files, see Acknowledgements and/orreports on page 61.

Tip: To download a response file from a browser, click the tools icon in the File Options columnof the file you want, and then click a download option such as text/plain, under Download and DeleteFiles. You can also download the file directly through your browser.






Note:

• Availity removes and archives response files remaining in the ReceiveFiles folder after 30 days,whether or not they've been downloaded. You can self-serve and restore archived response files for upto six months after the creation date. You can also request a copy of any archived response file fromAvaility Client Services regardless of the creation date.

• Availity removes and archives the notification files from the SendFiles folder each night, whether ornot they've been downloaded.

• The ReceiveFiles folder includes response files received for the entire organization. If you sendtransmission files to a clearinghouse or payer representative other than Availity, the responsefiles are sent to that clearinghouse or payer representative and you cannot access them. It is theirresponsibility to notify you of any issues identified in the response files. Contact the clearinghouse orpayer representative directly for assistance.

• For UCare and Medicare DMERC regions B, C, and D, Availity passes a proprietary response directlyfrom the payer to the provider. These response files have a .RPT extension and are direct passthrough without any mapping or editing by Availity.

• If an organization submits claims using Availity online claim forms and the payer processes claimsin batches, the payer's response also displays in the ReceiveFiles folder in an EBR file. If the EDIreporting preferences are set up to receive EBRs together in a single file, the payer's responses forWeb claims are mingled with payer responses for transmission files that were uploaded.



EDI transactions through Availity Portal

Setup steps for EDI through Availity Portal

Getting set up to submit batch files of EDI transactions to Availity through Availity Portal involves thefollowing steps, some of which you might have already completed. The integration testing step is optional.

1. Register with Availity - If you haven't already registered your organization with Availity, go towww.availity.com and click REGISTER.


2. Integration testing - Availity gives you the option of doing integration testing in our QA environmentbefore you submit any real transactions. See Integration testing and submitting to the productionenvironment on page 25 for details.

3. Set up your EDI reporting preferences - Availity's batch EDI processing generates response filesfor each batch file that you submit. The administrator for an organization can set reporting preferencesthat specify which response files are generated. See Set up EDI reporting preferences on page 31for details.

4. Enroll for transactions - You might need to enroll for some transactions (such as claim submission)for particular health plans that you submit to. To determine if any of the health plans that you submitto require enrollments, see the Availity payer list. You can also enroll (if required) to have electronicremittance advice files (also known as ERAs and 835s) delivered to your Availity mailbox. Electronicremittance advice files display payment information from all claims, whether submitted electronicallyor by paper. See the Availity payer list to determine if enrollment for ERAs is required for a particularhealth plan.

Note: If your ERAs are already delivered to Availity for the health plans that you submit claims to, youcan skip the ERA transaction enrollment process.






5. Set up your Availity Portal users - If other people in your organization need access to Availity Portal,such as to view remittance advice information, you'll need to create an Availity Portal account for eachsuch person. Log in to Availity Portal at https://apps.availity.com, click your name or the avatar icon inthe Availity Portal menu, and then click Add User.

Tip: Have a lot of users? On the Add Users page, click the option to upload users in a spreadsheetin .csv format.

Important: To manually upload transaction files through Availity Portal, users will need the EDIManagement role, which can be assigned by the administrator for your organization. Once the EDIManagement role has been assigned to a user, it might take up to 24 hours before that user can uploadfiles. Administrators automatically have the EDI Management role.




Integration testing and submitting to the production environment

Integration testingIntegration testing is coordinated through Availity Client Services at no charge to the submitter. Onceyou've received your user ID and password for your QA account from Availity Client Services, you'llbe able to log in at https://qa-apps.availity.com. The process for uploading batches of transaction files,viewing response files, and setting up which response files you receive is exactly the same in the QAenvironment as it is in the production environment.

Submitting to the production environmentOnce you've completed any testing you wanted to do in our QA environment, you're ready to startsubmitting transactions to our production environment through your Availity Portal account. If you did anyintegration testing, then just remember to log in through our production URL at https://apps.availity.com tosubmit your real transactions to our production environment.





Upload transaction files through Availity Portal

Note: In order to send and receive files through Availity Portal you'll need to have both cookies andjavascript enabled in your browser.

To upload an EDI batch file of transactions through Availity Portal, follow these steps:

1. In the Availity Portal menu, click Claims & Payments > Send and Receive EDI Files.

2. In the Organization field, on the Send and Receive EDI Files page, select the appropriateorganization, and then click Submit.

3. On the Send and Receive Files page, click SendFiles to upload files to Availity.



4. Click Choose Files, select the file that you want to upload, and then click Open.

5. Verify that the file displayed to the right of the Choose Files button is the file you want, and then clickUpload File. Availity will then process the file that you uploaded.

Availity returns a notification file to your SendFiles folder indicating whether a batch file was accepted forprocessing. For details, see the topic on the Notification file on page 73.

Important: Availity removes and archives the notification files from the SendFiles folder each night,whether or not they've been downloaded.



Download EDI response files from Availity Portal

Availity's batch EDI processing generates response files for each batch file that you submit. When you'remanually uploading batch files through Availity Portal, you'll want to retrieve all response files on a regularbasis to track the transactions that you submitted. Your administrator can specify which responses youreceive.

Response files include Acknowledgements, Immediate Batch Reports, Electronic Batch Reports, andDelayed Payer Reports.

• Acknowledgements identify file-level issues.

• Immediate Batch Reports, Electronic Batch Reports, and Delayed Payer Reports identify claim-levelissues. They contain the information needed to correct and resubmit transactions.

And if you elected to receive electronic remittance advice files (also known as ERAs and 835 files)through the Availity Health Information Network, you'll retrieve those files from the same location as yourresponse files.

Note: In order to send and receive files through Availity Portal you'll need to have both cookies andjavascript enabled in your browser.

To download response files from Availity Portal, follow these steps:

1. In the Availity Portal menu, click Claims & Payments > Send and Receive EDI Files.

2. In the Organization field, on the Send and Receive EDI Files page, select the appropriateorganization, and then click Submit.



3. On the Send and Receive Files page, click ReceiveFiles to retrieve files from Availity. TheReceiveFiles folder includes response files for all EDI batches submitted by your organization.

4.To download a response file, click the tools icon in the File Options column of the file you want,and then click a download option such as text/plain, under Download and Delete Files. You can alsodownload the file directly through your browser. For descriptions of the types of response files, seeAcknowledgements and/or reports on page 61.



Note:

• Availity removes and archives response files remaining in the ReceiveFiles folder after 30 days,whether or not they've been downloaded. You can self-serve and restore archived response files for upto six months after the creation date. You can also request a copy of any archived response file fromAvaility Client Services regardless of the creation date.

• Availity removes and archives the notification files from the SendFiles folder each night, whether ornot they've been downloaded.

• The ReceiveFiles folder includes response files received for the entire organization. If you sendtransmission files to a clearinghouse or payer representative other than Availity, the responsefiles are sent to that clearinghouse or payer representative and you cannot access them. It is theirresponsibility to notify you of any issues identified in the response files. Contact the clearinghouse orpayer representative directly for assistance.





Set up EDI reporting preferencesAvaility's batch EDI processing generates response files (acknowledgements and reports) for eachsubmitted batch file. Availity provides standard response files recommended in the official HIPAAimplementation guides (called TR3s) and proprietary reports for end-to-end tracking and accountability ofeach submitted transaction.

The administrator for an organization can set up reporting preferences that specify which response filesare generated. Response files are retrieved from your ReceiveFiles folder.

To set EDI reporting preferences, follow these steps:

1. In the Availity Portal menu, click Claims & Payments > EDI Reporting Preferences.

2. On the EDI Reporting Preferences page, select the organization that you're setting preferences for.



3. On each of the EDI Reporting Preferences tabs, for example the Claims tab (partial view) below,specify the preferences you want, and then click Save to save the preferences for that tab. Changesare saved on a per tab basis.

• Some responses, such as the Negative interchange acknowledgement, are required (per HIPAAguidelines) and are automatically generated. The associated check box is checked and grayed outto indicate that it can't be unchecked.

• You can view detailed information for a particular preference setting by clicking the blue questionmark next to the label for the setting.

• File extensions for each report type are listed to the right of the report option, such as .ACK, .IBR,and others. The file extension consists of the characters that display after the period at the end ofthe file name for the report or response file. It indicates the type of file and can help you identifywhich report or response file types are listed in the ReceiveFiles folder.

• When you group EDI response files by payer on the EDI Reporting Preferences page, the responsefile returned to the ReceiveFiles folder will include the payer short name in the file name.

• Changing the file format (for example, from delimited to text-human readable) only affects responsefiles that are created after you save the change to the file format. Response files that were createdprior to the file format change will remain in their original format.



EDI reporting preferences for claims

The Claims tab of the EDI Reporting Preferences page is where you specify the types of responses thatyou want when you submit claims through Availity.

The following types of response files are associated with Claims:

• File acknowledgements

• Interchange acknowledgements (TA1)

• Implementation acknowledgements (999)

• Immediate batch responses (IBR)

• Electronic batch reports (EBR)

• Delayed payer reports (DPR)

We'll describe the preferences for each type of response file in a separate section below.

Important: When you're done making any changes on this tab, click Save before moving on to anothertab. Changes are saved on a per tab basis.

Preferences for File AcknowledgementsAvaility automatically sends a negative file acknowledgement (ACK) to your organization's ReceiveFilesfolder when a submitted batch file fails Availity's proprietary validation, most commonly when the fileformat is invalid.

The Negative file acknowledgements check box is selected and grayed out, meaning that you alwaysreceive negative file acknowledgements.

You can receive this file in a computer-readable or human-readable format.

• Select Delimited (.ACK) to receive a delimited file format that you can import into a computer system.

• Select Text - Human readable (.ACT) to receive a text file that you can read. This is the default.

• Delimited files can be imported into a PMS, HIS, or other automated system. Technical personnel whooversee computer systems in your organization might also open and view this file.

• If you will not be importing the file into a computer, we recommend that you select the text file.



Preferences for Interchange Acknowledgements (TA1)Availity automatically sends negative interchange acknowledgements to your organization's ReceiveFilesfolder. This file reports errors encountered within the interchange header or trailer of the X12 file,particularly errors caused by duplicate interchange control numbers or an incorrect trading partnerenvelope.

• The Negative interchange acknowledgements check box is selected and grayed out, meaning thatyou always receive negative interchange acknowledgements.

• To receive positive interchange acknowledgements, the value of ISA14 must be set to 1 in thesubmitted batch file. Positive interchange acknowledgements are returned with the implementationacknowledgement file (999).


• Select X12 (.TA1) to receive an X12 file that you can import into a computer system. This is thedefault.

• Select Text - Human readable (.TAT) to receive a text file that you can read.

• X12 files can be imported into a PMS, HIS, or other automated system. Technical personnel whooversee computer systems in your organization might also open and view this file.


Note: The format selection applies to both negative and positive interchange acknowledgements.

Preferences for Implementation Acknowledgements (999)Availity automatically sends negative implementation acknowledgements to your organization'sReceiveFiles folder. This file indicates that Availity received the transmission file and it had errors,particularly X12 and HIPAA syntax errors. Implementation acknowledgements are also referred to as 999files.



• The Negative acknowledgements check box is selected and grayed out, meaning that you alwaysreceive negative implementation acknowledgements.

• To receive positive implementation acknowledgements that acknowledge the receipt and successfulvalidation of each functional group within your batch files, select the Positive acknowledgementscheck box.


• Select X12 to receive an X12 file format that you can import into a computer system. This is thedefault.

• Select Text - Human readable to receive a text file that you can read. These reports contain similarinformation as the data files, but are intended for viewing by non-technical users.


Note: The format selection applies to both negative and positive implementation acknowledgements.

Select Include TA1 to include the positive TA1 with the acknowledgement. To generate a positive TA1,the value of ISA14 must be set to '1' in the submitted batch file.

Preferences for Immediate Batch Response (IBR)The immediate batch response (also referred to as an IBR) is a proprietary report that acknowledgesaccepted claims and identifies rejected claims due to HIPAA edits and payer-specific edits (PSEs) thatAvaility conducted on behalf of payers. The report also includes claim counts and charges at the claimlevel and file level. Only claims that passed file format and syntax validations are included in this report.



The Immediate Batch Response (IBR) is available in both a pipe-delimited data file and a formatted-textreport. You can also opt to receive immediate batch responses in the 277CA claim acknowledgementformat. All of these reports are optional.

• Select Data Report (.IBR) to receive IBRs in a pipe-delimited format. Pipe-delimited files can beimported into a PMS, HIS, or other automated system. Technical personnel who oversee computersystems in your organization might also open and view these files.

• Select Text Report (.IBT) to receive IBRs in a text format intended for viewing by non-technical users.

• Select 277CA (.277IBR) to receive immediate batch responses in the 277CA claim acknowledgementformat. The 277CA file is an X12 file that you can import into a computer system.

Preferences for Electronic Batch Reports (EBR)The electronic batch report (also referred to as an EBR) is a proprietary report that provides the status(received from the payer) for each transaction in the original submission. The report contains summarycounts of transactions received and accepted, and lists detailed information for rejected transactions,including payer specific edits (PSEs) and HIPAA edits. Only claims that passed file format and syntaxvalidations are included in this report.

The Electronic Batch Report (EBR) is available in both a pipe-delimited data file and a formatted-textreport. You can also opt to receive electronic batch reports in the 277CA claim acknowledgement format,in conjunction with the pipe-delimited or text report format. All of these reports are optional.

• Select Data Report (.EBR) to receive electronic batch reports in a pipe-delimited format. Pipe-delimited files can be imported into a PMS, HIS, or other automated system. Technical personnel whooversee computer systems in your organization might also open and view these files.

• Select Summary Data Report (.EBR) to receive a summary which includes only prepaymentdetails and errors for rejected claims. This report does not include accepted claims details.

Note: The rejected claims display the message text and other information from the payer but theaccepted claims do not display this information.

• Select Detail Data Report (.EBR) to receive a report including acknowledgement of all claims inthe transmission file. This option includes the results of edits at both Availity and the receiver orpayer for accepted claims, prepayment details, and rejected claims and important messages fromthe health plan.

Note: The detail report is recommended.



• Select Text Report (.EBT) to receive electronic batch reports in a text format intended for viewing bynon-technical users.

• Select Summary Report (.EBT) to receive a summary which includes only prepayment details anderrors for rejected claims. This report does not include accepted claims details or rejection reasons.To receive rejection details, select the detail report.

Note: The rejected claims display the message text and other information from the payer but theaccepted claims do not display this information.

• Select Detail Report (.EBT) to receive a report including acknowledgement of all claims in thetransmission file. This option includes the results of edits at both Availity and the receiver or payerfor accepted claims, prepayment details, and rejected claims and important messages from thehealth plan.


• Select 277CA (.277EBR) to receive electronic batch reports in the 277CA claim acknowledgementformat. The 277CA file is an X12 file that you can import into a computer system.

Note: The .277EBR can only be received in combination with the .EBR or .EBT. If you do not selectthe .EBR or .EBT, the .277EBR will not be sent.

Preferences for Delayed Payer Reports (DPR)The delayed payer report (also referred to as a DPR) includes information from payers that utilizebatch processing or other non-real-time adjudication processes. The report includes transaction receiptacknowledgement, transaction reject messaging, warning, and informational messages, as well asadjudication responses returned by the destination payer.

The Delayed Payer Report (DPR) is available in both a pipe-delimited data file and a formatted-textreport. You can also opt to receive delayed payer reports in the 277CA claim acknowledgement format, inconjunction with the pipe-delimited or text report format. All of these reports are optional.

• Select Data Report (.DPR) to receive delayed payer reports in a pipe-delimited format. Pipe-delimitedfiles can be imported into a PMS, HIS, or other automated system. Technical personnel who overseecomputer systems in your organization might also open and view these files.



• Select Text Report (.DPT) to receive delayed payer reports in a text format intended for viewing bynon-technical users.

• Select Summary Report (.DPT) to receive a summary.

• Select Detail Report (.DPT) to receive a detail report including acknowledgement of all claims inthe payer's response and important messages from the health plan.


• Select 277CA (.277DPR) to receive delayed payer reports in the 277CA claim acknowledgementformat. The 277CA file is an X12 file that you can import into a computer system.

Note: The .277DPR can only be received in combination with the .DPR or .DPT. If you do not selectthe .DPR or .DPT, the .277DPR will not be sent.

EDI reporting preferences for claim payment/advice

The Claim Payment/Advice tab of the EDI Reporting Preferences page is where you specify preferencesfor your claim payment/advice files. These files are referred to as electronic remittance advice (ERA) filesor 835 files.



• You can select the HIPAA version (5010 or 5010A1) of your electronic remittance advice files. Thedefault is 5010A1. If the payer sends a different version, Availity will convert the files for you.

• You can group your electronic remittance advice files by organization, provider, or payer.

• You can limit the maximum file size by number of checks or by number of bytes.

• You can schedule multiple deliveries of your electronic remittance advice files throughout the day.

BCBSIL, BCBSNM, BCBSOK, BCBSTX

You cannot use the 835 Save/Delivery Options to convert (up or down-convert) the 835 version.




EDI reporting preferences for non-claim transactions

The Non-Claim Transactions tab of the EDI Reporting Preferences page is where you specifypreferences for claim status responses, eligibility & benefits responses, and authorization/referralresponses.

• You can group the response files for your non-claim transactions by organization and payer, or byprovider and payer, or you can choose not to group the response files.

• You can choose to receive immediate responses or schedule multiple deliveries of your non-claimtransaction response files throughout the day.

• For authorization and referral responses, you can receive a summary text report that displays theinformation in a form that's intended for non-technical users.




EDI reporting preferences for mail box options

The Mail Box Options tab of the EDI Reporting Preferences page is where you specify generalpreferences that apply to all response files.

• You can choose to receive all of your X12 response files with carriage returns after each line, whichmakes the files easier to read. If your system can't accept carriage returns and line feeds or you'd liketo receive one stream of data, uncheck this option.

• You can choose to have your response files delivered together in a single ZIP file.




Restore archived filesIf you're looking for a particular response file in your ReceiveFiles folder and can't find it, note that Availityarchives response files remaining in the ReceiveFiles folder after 30 days, whether or not they've beendownloaded. You can, however, restore any files archived from your ReceiveFiles folder within the past6 months without having to contact Availity Client Services. And you can actually restore up to 2,000 filesper request.

Note: To restore response files that are more than six months old, you'll need to contact Availity ClientServices.

To restore archived files, follow these steps:

1. In the Availity Portal menu, click Claims & Payments > File Restore (under EDI Clearinghouse)

2. In the Organization field, on the File Restore page, select the organization associated with the filesyou want to restore.



3. By default, the Basic tab is selected on the File Restore page. As shown in the figure above, theBasic tab allows you to search for a single file by batch ID. To search for one or more files by daterange, file type, and/or keywords, click the Advanced tab.



4. Whether you're searching from the Basic tab or from the Advanced tab, enter search criteria in thefields provided, and then click Search.

Consider the following guidelines when you're searching from the Advanced tab:

• Selecting a date range – Click the calendar button to select the date range.

• Click one of the pre-defined date ranges, or click Custom Range to specify a custom daterange.

• For custom date ranges, click the start date and end date in the calendars provided, and thenclick Apply.

• Selecting file types – Select one or more file types. You can remove a file type by clicking the icon next to the file type.

• Searching by keywords – Enter one or more words contained in the names of the files you wantto restore. Keywords are optional and case-sensitive.

• Restoring as individual or zip files – Click Individual Files to restore each file individually, orclick Zip File to restore the files in a ZIP file.

Note: ZIP file names begin with RestoredFiles, followed by the date range, and then the fileextensions (e.g., DPT, EBT, ERA, IBT) of the files that were restored.

5. Select the check box next to each file you want to restore, and then click Restore Selected Files.

Note: Click Back to Search to change your search criteria.

The results page displays the EDI files that were restored. Click Receive Files on the results page toview the restored EDI files.



Tips for successful batch file submissions• Need information about how electronic professional claims match up to paper CMS-1500 forms? See

this quick reference guide.

• Most errors occur due to data entry mistakes and accidentally skipped fields. To reduce errors, alwaysverify the data you enter in your system before batching the claims, inquiries, and requests, andsubmitting them to Availity.

• If you are submitting a rebatched transaction file, be sure it contains a new interchange control number(ICN). Files with duplicate control numbers will be rejected.

• Verify you are using the most current procedure and diagnosis code lists available.

• Do not use decimals in procedure or diagnosis codes. For example, submit 525.25 as 52525.

• Do not use decimals in whole-dollar charge amounts. For example, submit $27.00 as 27.

• For charge amounts involving cents with more than two decimal places, round the amount to thenearest penny. HIPAA rejects amounts submitted with more than two decimal places. For example,submit $59.99223 as 59.99.

• Ensure all dates are valid date values using the correct format, YYYYMMDD.

• Do not enter dashes in zip codes.

• If you enter dashes in social security, federal tax ID, and employer ID numbers, Availity will removethem.

• Make sure the correct payer-assigned provider ID is in the Provider ID field, and the tax ID is in theTax ID field.

• For Medicare claims, do not enter the subscriber's social security number.

• Do not use special characters, such as colons or asterisks (*). They might be confused withdelimiters, which are special characters used to separate data in ANSI X12 files. Also, due to multipleconversions, the characters may translate differently.

• Do not enter trailing spaces in elements when it is not required for a minimum length.

• Submit up-to-date and specific ICD-10, CPT, and HCPCS codes. Availity applies the code set effectivedates as established by code owners (administrators).

• ICD-10 is updated annually on October 1 as directed by CMS

• CPT and HCPCs are released on January 1 with quarterly updates


https://apps.availity.com/availity/documents/edi%20guide/CMS_1500_Quick_Reference_Guide.pdf


• Only bill claims for services that have already occurred. The claim dates of service must be prior to thetransaction creation date. Other examples of dates that must be prior to the transaction creation dateare:

• Onset of Current Symptom/Illness

• Subscriber Birth Date

• X-ray Date

• Date Last Seen

• Initial Treatment Date

• Last Certification Date

• Service Date

• Last Certification Date

• Always include the admission date on inpatient claims.

• Availity accepts up to 50 service lines per claim.

• Do not enter a value of 6 for Claim Frequency Codes.

• Do not enter e-codes for the primary diagnosis or the admitting or patient reason for visit.

• Do not use value XV for the National Plan ID.

For claims involving oxygen therapy

• The Service Line Date of Oxygen Saturation/Arterial Blood Gas Test is required on the initial oxygentherapy service line. Technically speaking, segment CR5 is used in loop 2400 and CR501 is I.

• Segment 2420E PER is required when services involving an oxygen therapy CMN are being billed/reported on this service line and segment DTP 'Date Oxygen Saturation/Arterial Blood Gas Test' inloop 2400 is used.

For authorization, referrals, and certifications

When the certification is for home health care, private duty nursing, or services by a nurses' agency, thenthe CR6 segment is required.



System status, scheduled maintenance, and cut-off times

System statusYou can check the status of the Availity network by visiting the Availity Network Outage Notification pageat https://www.availity.com/status/. The Availity Network Outage Notification page provides details aboutthe following:

• Current outages

• Recently resolved outages

• Scheduled maintenance

Scheduled maintenanceSo that we can keep the computer and network operations centers running smoothly, and provide youwith new product features, Availity performs scheduled maintenance on the data center computers andnetwork servers. Scheduled maintenance is posted on the Scheduled Maintenance tab on the AvailityNetwork Outage Notification page at https://www.availity.com/status/.

• Availity makes every effort to complete all scheduled maintenance within the scheduled maintenancewindow.

• Major upgrades are scheduled during weekend hours. Major upgrades can include, but are not limitedto, software upgrades, operating system upgrades, and reconfiguration of network routers.

• Upgrades requiring more than a day's work are scheduled for holiday periods.

• Some maintenance, either scheduled or emergency, might force interruptions to production services.In such cases, we'll post a notification in the News and Announcements section on the Home pageof Availity Portal. Outage details are also provided on the Availity Network Outage Notification page.

• Availity has a recovery plan for failed upgrades of software or hardware to ensure that services areunavailable for the least amount of time possible.

Cut-off timesMost payers and/or payer contractors have a designated cut-off time for transmission files to beprocessed in each day's cycle. To ensure that your files are processed in a particular day's cycle, you willneed to contact the payer to determine their particular cut-off time, if any. For reference, Availity edits,bundles, and forwards accepted claims daily to each payer and/or payer contractor (receiver) and has nocut-off time for submissions.

Note: Payer responses reflect the date and time that Availity received the transactions.


https://www.availity.com/status/

https://www.availity.com/status/


Confidentiality and access, transaction platforms and deletion oftransactions• Availity treats all EDI submissions confidentially. The information is used for internal Availity business

purposes only and always within the privacy and security guidelines established by HIPAA.

• Availity processes all transactions submitted to the Availity Health Information Network productionenvironment/web site and forwards them to payers for adjudication and processing, regardless of thetest/production indicator within the ISA segment of the transaction set.

• Availity does not delete any production transactions accepted through the Availity Health InformationNetwork. If your office submits any transactions in error, your office must handle the issue with thepayer.

• Availity rejects any transactions submitted with invalid payer identification and reports the transactionsas invalid on the Availity Immediate Batch Response (IBR) (If you have chosen to receive the IBR)unless the entire file is rejected for invalid payer identification. If the entire file is rejected, an ElectronicBatch Report (EBR) is generated. You must review, correct, and resubmit these transactions in a newbatch file containing a unique batch control number.



Transaction response aggregationIn support of the HIPAA-mandated EDI standard transactions, Availity accepts non-claim transactions(270/271, 276/277, and 278) in a batch file format, performs HIPAA compliance validation and forwardsthose that pass validation to the payers. Responses to these transactions and 835 remittance advice filesare also received and processed by Availity for the payers supporting this functionality.

• Transactions submitted for real-time payers usually result in a response in your ReceiveFiles mailboxwithin 24 hours or less.

• Transactions for Blue plans outside of your home Blue plan can result in the following types oftransaction responses: interim acknowledgement within 24 hours or less; payer benefit/rejection within72 hours. The interim response is returned in the X12 standard paired response transaction format(i.e. 271, 277, 278).

Within the constraints of the hierarchy (HL) and loops defined in the ANSI ASC X12N HIPAAimplementation standards, there can be a number of different ways of aggregating information for a giventransaction. This is especially true in the paired transactions such as the 270/271 and the 276/277 andthe 278. For example, inbound transaction sets (ST/SE) that have many business transactions can havea single business transaction in each ST/SE in the response transactions. This is compliant and anyHIPAA-compliant PMS or system translator has no problem accepting the transactions in this format.

During processing, Availity breaks down inbound transactions to the smallest logical business transactionand sends that transaction content to the payer. For example, your inbound batch 837 EDI claims filecontains a total of 100 claims for 60 unique patients for services rendered by 6 different providers inyour provider group. Upon receipt and validation of the inbound EDI file, the Availity Health InformationNetwork process creates 100 individual standalone ANSI ASC X12N 837 compliant transactions, eachwith their own ISA/IEA, to send to the designated payers.



Contact information

Availity Client ServicesFor questions, assistance, and support, log in to Availity Portal and submit an online support ticket (24/7)by navigating to Help & Training > Availity Support, at the top of Availity Portal. Or, contact an AvailityClient Services representative at 1.800.AVAILITY (282.4548).

Hours of operation: Monday through Friday

Eastern Time Zone Central Time Zone Mountain Time Zone Pacific Time Zone

8:00 a.m. to 8:00 p.m. 7:00 a.m. to 7:00 p.m. 6:00 a.m. to 6:00 p.m. 5:00 a.m. to 5:00 p.m.

For issues with specific EDI transactions, please be prepared to provide the batch ID of the batchthat contains your issue. The batch ID is a unique, 16-digit date-timestamp that Availity assigns toan EDI transmission file when you upload and submit it through Availity. The ID takes the formatYYYYMMDDHHMMSSSS. For EDI transactions submitted through a third-party clearinghouse, contactthat clearinghouse for the batch ID.



Control segments/envelopesThe Availity Health Information Network processing is operationally compliant with the Interchange andApplication Control Structures standards defined in Appendix B of each 5010 HIPAA TR3. This sectiondetails the specific addressing and control values expected in the following segments of batch X12 filesthat are submitted to Availity:

• Interchange Control Header and Trailer (ISA/IEA)

• Functional Group Header and Trailer (GS/GE)

• Loop ID – 1000A Submitter Name (claims)

• Loop ID – 1000B Receiver Name (claims)

Adherence to these specifications is necessary to provide sufficient discrimination for the payer routingand acknowledgement process to function properly and to ensure that audit trails are accurate.

Note: The content in this section is intended for users who are setting up X12 files for submission toAvaility. As such, it requires a detailed understanding of the structure and content of X12 files.

Interchange Control Header (ISA) and Interchange Control Trailer(IEA) segmentsThe ISA segment is the only EDI segment with a fixed length. A total of 105 positions are allowed in theISA segment, including the letters ISA, the asterisk (*) or other value used as a data element separator(also known as an element delimiter), and the colon (:) or other sub-element separator (also known asa composite element delimiter). The value in position 106 is reserved for the tilde (~) or other segmentterminator character used to denote the end of each segment.

Once specified in the interchange header, the delimiters and terminators cannot be used in a dataelement value elsewhere in the file. Availity can accept as a data element any value in the Basic andExtended Character Sets referenced in Appendix B.1.1.2 of 5010 ANSI X12N Implementation Guides,and accepted as X12 standard compliant.

When Availity processes your batch, we create a new ISA/IEA for each transaction we develop and sendto the payer. Availity currently uses the following values for delimiters and terminators and requests thatyou not use these values in any element text.

Usage Value

Data element separator '*' Asterisk

Sub-element separator ':' Colon

Segment terminator '~' Tilde

Repetition separator (5010) '^' Caret

The following rules apply to multiple functional groups and multiple transaction sets:

• Multiple Functional Groups (GS/GE) within an Interchange (ISA/IEA) must be numbered uniquely,using the Group Control Number data element (GS06). It is recommended that the GS06 be uniquewithin all transmissions over a period of time.



• Multiple Transaction Sets (ST/SE) within a Functional Group (GS/GE) must be numbered sequentiallybeginning with 1 in the first Transaction Set Control Number data element (ST02).

Interchange Control Header (ISA) segmentThe following table defines the requirements for the Interchange Control Header (ISA) segment. When avalue for a required field is specified in the Specifications column, the specified value is required in allfiles submitted to Availity.

ISA segments

Field Usage Specifications Segment

AuthorizationInformation Qualifier

Code to ID the typeof information in theauthorization

• Required

• Length: 2/2

• Required Value: 00 = NoAuthorization Information Present

Note: For EDI batch mode, logincredentials are not provided inthe ISA header.

ISA01

AuthorizationInformation

Info used foridentification orauthorization of thesender or the datainterchange

• Required

• Length: 10/10

• Required Value: (10 blankspaces)

ISA02

Security InformationQualifier

Code to ID the typeof information in theSecurity Info

• Required

• Length: 2/2

• Required Value: 00 = No SecurityInformation Present

Note: For EDI batch mode, logincredentials are not provided inthe ISA header.

ISA03

Security Information Info used for identifyingsecurity informationabout the sender or thedata interchange

• Required

• Length: 10/10

• Required Value: (10 blankspaces)

ISA04

Interchange IDQualifier

Qualifier to denotethe system/method ofcode structure used todesignate the sender

• Required

• Length: 2/2

• Required Value: ZZ = MutuallyDefined

ISA05




Interchange Sender ID ID code for sender,as defined by Availity.This ID is qualified bythe value in ISA05

• Required

• Length: 15/15

• Required Value: AV09311993 (+5blank spaces)

ISA06

Interchange IDQualifier

Qualifier to denotethe system/method ofcode structure used todesignate the receiver

• Required

• Length: 2/2

• Required Value: 01 = Duns (Dun& Bradstreet)

ISA07

Interchange ReceiverID

ID code published bythe receiver. This ID isqualified by the value inISA07.

• Required

• Length: 15/15

• Required Value: 030240928 (+6spaces)

ISA08

Interchange Date Date of the interchange • Required

• Format: YYMMDD

ISA09

Interchange Time Time of theinterchange

• Required

• Format: HHMM

ISA10

Repetition Separator Provides the delimiterused to separaterepeated occurrencesof a simple dataelement or a compositedata structure

• Required

• Length: 1/1

• Recommended Value = ^

ISA11

Interchange ControlVersion Number

This version numbercovers the interchangecontrol segments

• Required

• Length: 5/5

• Required Value: 00501

ISA12

Interchange ControlNumber

A unique controlnumber assigned bythe sender

• Required

• Length: 9/9

• Recommended Value: Must beidentical to the value in IEA02

ISA13




AcknowledgementRequested

Code sent by thesender to requestan interchangeacknowledgement(TA1)

• Required

• Length: 1/1

• Recommended Value = 1

ISA14

Usage Indicator Code to indicatewhether data enclosedis test or production.Test until all Availityvalidation testing iscomplete then set to Pfor Production.

• Required

• Length: 1/1

• Recommended Values = T(Testing) or P (Production)

ISA15

Component ElementSeparator

The sender identifiesthe element separatorused as a delimiterto separate the datawithin a compositedata structure. Must bedifferent from the dataelement separator andsegment terminator.

• Required

• Length: 1/1

• Recommended Value: Any valuefrom the Basic Character Set.

ISA16

Segment Terminator Always use tilde assegment terminator.There will be no linefeed in X12 code.

• Required

• Position 106 1/1

• Required Value = "~" [Tilde]

ISA

Interchange Control Trailer (IEA) segmentThe following table define the requirements for the Interchange Control Trailer (IEA) segment, which ispaired with the Interchange Control Header (ISA) segment.

IEA segments


Number of IncludedFunctional Groups

A count of the numberof functional groupsincluded in theinterchange

• Required

• Field Length: 1/5

IEA01

Interchange ControlNumber

A control numberassigned by the sender

• Required

• Field Length: 9/9 (same asISA13)

IEA02



Functional Group Header (GS) and Functional Group Trailer (GE)segmentsThe Functional Group Header (GS) segment indicates the beginning of a functional group of transactionsets and provides control information for acknowledgements and other reporting. Availity can accept aninterchange with multiple mixed transaction types GS/GE Functional Groups. Please review AppendicesA & B in the HIPAA IGs and Appendices B & C in the HIPAA TR3s of the transaction being generated foradditional details.

Functional Group Header (GS) segmentThe following table defines the requirements for the Functional Group Header (GS) segment.

GS segments


Functional IdentifierCode

Code identifying agroup of applicationrelated transaction sets

• Required


• Recommended Values: [varybased on transaction type]

• HI = Health Care ServicesReview Information (278)

• HR = Health Care ClaimStatus Request (276)

• HN = Health Care ClaimStatus Notification (277)

• HC = Heath Care Claim (837)

• HS = Eligibility, Coverage orBenefit Inquiry (270)

• HB = Eligibility, Coverage orBenefit Information (271)

• HP = Health Care ClaimPayment/Advice (835)

• FA = 999 ImplementationAcknowledgement (5010)

GS01

Application Sender'sCode

Code Identifying partysending transmission.Code agreed to bytrading partners.

• Required


• Recommended Value (5010):Vendor partners should enter thevendor's customer ID.

GS02




Application Receiver'sCode

Code identifying partyreceiving transmission.Code agreed to bytrading partner.

• Required


• Required Value: 030240928

GS03

Date Creation Date • Required


• Format: CCYYMMDD

GS04

Time Creation Time • Required


• Format: HHMM (GMT/UTCStandard)

GS05

Group Control Number Assigned numberoriginated andmaintained by thesender

• Required


Note: Do not use leading zeroes

• Must be unique withininterchange

• Recommended to be unique overa 6-month period

• Must match GE02

GS06

Responsible AgencyCode

Code used to identifythe issuer of thestandard

• Required


• Recommended Value: X =Accredited Standards CommitteeX12

GS07




Version / Release /Industry Identifier Code

Code indicating theversion, release, subrelease, and industryidentifier of the EDIstandard being used

• Required


• Recommended Values: [varybased on transaction type]

• 835 – 005010X221A1

• 270/271 – 005010X279A1

• 276/277 – 005010X212

• 278 – 005010X217

• 278N – 005010X216

• 837 Institutional –005010X223A2

• 837 Professional –005010X222A1

• 837 Dental – 005010X224A2

GS08

Functional Group Trailer (GE) segmentThe following table defines the requirements for the Functional Group Trailer (GE) segment, which ispaired with the Functional Group Header (GS) segment.

GE segments


Number of TransactionSets Included

Total number oftransaction sets (ST/SE) included in thefunctional group orinterchange

• Required


GE01

Group Control Number Assigned numberoriginated andmaintained by thesender. The datainterchange controlnumber GE02 inthis trailer must beidentical to the samedata element in theassociated functionalgroup header, GS06.

• Required


GE02



Submitter (1000A) and Receiver (1000B) loopsThe following table defines the requirements for the Submitter (1000A) and Receiver (1000B) loops.

Loop ID Segment Element Name Description Requirement

1000A NM1 Submitter Nameand ID

To supply thefull name of anindividual ororganizational entity

Senders must submit thesubmitter name (NM103) andsubmitter identifier (NM109)assigned by the destinationpayer

1000B NM1 Receiver Name andID

To supply thefull name of anindividual ororganizational entity

• Senders can submit thedestination payer name(NM103) and payer ID(NM109)

• For BCBSF (FloridaBlue) use tax ID number592015694. For Humana,use their Dun & Bradstreetnumber 049944143

• Other Payer IDs areavailable in Availity HealthPlan Partners list

• Senders can also submitwith NM103 equal toAvaility and the AvailityDun & Bradstreet number030240928 in NM109



CAQH CORE Phase II connectivityIn support of the CAQH CORE Phase II mandate, Availity offers a fully compliant connectivity solution viathe following URL:

https://gateway.availity.com:2021/core

Availity can receive batch files using either Envelope Standard A (HTTP MIME Multipart) or EnvelopeStandard B (SOAP+WSDL) and requires that Submitter Authentication Standard C (User name/Password) use the UserName and Password fields for Envelope Standard A and WS-security forEnvelope Standard B. For more information, see Phase I CORE 153: Eligibility and Benefits ConnectivityRule and Phase II CORE 270: Connectivity Rule

The following table displays the CORE Phase II field level requirements:

Field Description

Payload Type Specifies the type of payload included within therequest. Must be one of the following:

• X12_270_Request_005010X279A1

• X12_276_Request_005010X212

• X12_278_Request_005010X215

• X12_278_Request_005010X216

• X12_278_Request_005010X217

• X12_837_Request_005010X223A2

• X12_837_Request_005010X222A1

• X12_837_Request_005010X224A2

ProcessingMode RealTime or Batch

PayloadID The unique payload identifier

TimeStamp The following is an example of a valid timestamp:20121130T22:30:06-5:00

SenderID The submitting entity identifier

ReceiverID The requested health plan identifier

CORERuleVersion The CORE rule version that this envelope is using(not required)

Payload Contains inline X12 transactions for real-timeservice or an attachment for batch

The following table displays the CORE Phase II services supported by Availity:


https://gateway.availity.com:2021/core

http://www.caqh.org/pdf/CLEAN5010/153-v5010.pdf




Service name Description

realTimeTransaction Submit a real time transaction, synchronous call.

batchSubmitTransaction Submit a file to Availity for processing as anMTOM request. The payload contains anattachment to the web service call.

batchSubmitAckRetrievalTransaction Retrieve a list of file names available for retrieval.The list of files, separated by a comma, is in theResponse object, Payload element.

batchResultsRetrievalTransaction Retrieve a single file (provide the file name inthe payloadID) and receive the file as an MTOMattachment in the response.

For more information on CAQH CORE Phase II Operating rules, see CAQH CORE Phase II OperatingRules.


http://www.caqh.org/CORE_phase2.php

http://www.caqh.org/CORE_phase2.php


Acknowledgements and/or reportsAvaility's batch EDI processing generates response files (acknowledgements and reports) for eachsubmitted batch file. Availity provides standard response files recommended in the official HIPAAimplementation guides (called TR3s) and proprietary reports for end-to-end tracking and accountability ofeach submitted transaction.

The following types of response files are available:

Notification file

Indicates whether a batch file was successfully received by Availity and recognized as a batch file.

File acknowledgement (ACK)

Indicates that a batch file failed Availity proprietary validation, and usually means that the format of thebatch file (which is expected to be X12) is invalid.

Interchange acknowledgement (TA1)

Indicates that the interchange control header (ISA) or interchange control trailer (IEA) segments of abatch file are invalid.

Implementation acknowledgement (999)

Reports the acceptance or rejection of each transaction set (ST/SE) in a batch file, based on whether anyX12 syntax errors were detected.

Immediate batch response (IBR)

Acknowledges claims accepted by Availity and identifies claims that were rejected due to HIPAA edits orpayer-specific edits (PSEs) conducted by Availity on behalf of payers. These response files are typicallyavailable within minutes after submitting a batch file, but can take up to 24 hours depending upon thevolume of claims processing at that time.

Electronic batch report (EBR)

Contains aggregated responses from payers and trading partners (such as other clearinghouses) aboutthe status of submitted claims. The report is typically available 24-48 hours after claims accepted byAvaility are submitted to a payer.

Delayed payer report (DPR)

Contains aggregated claim status information from payers that utilize batch processing or other non-real-time adjudication processes, or in cases where a payer response is received after Availity has alreadysent an EBR to your organization. The report is typically available within 30 days after claims accepted byAvaility are submitted to a payer. This report is not available for all payers.



Payer responses for non-claim transactions

Response files for non-claim transactions include the following: eligibility & benefits responses (.271),claim status responses (.277), authorization/referral (.278), health care services review notification andacknowledgement (.278N), and health care services review (.278ebr) summary text report.

All response files, except notification files, are available from the ReceiveFiles folder for an organization.The administrator for an organization can set up reporting preferences that specify which responsefiles are generated, the delivery schedule, and grouping options. Notification files are available from theSendFiles folder for an organization.

Note: If an organization registered to receive electronic remittance advice files (also known as ERAs and835 files) through Availity, the ERA files are available from the ReceiveFiles folder for the organization.

The following figure shows the response files that can be generated as an EDI file is processed byAvaility.



EDI response files by transactionThe type of response files generated depend on the transaction type and the edit level being reported.The following table lists each type of response file that an Availity non-payer submitter might receive, thefile extension and applicable transactions.

File name Extension 837 835 270/271 276/277 278/278 278N/278N

FileAcknowledgement

.ACK X X X X X

FileAcknowledgementReadable

.ACT X X X X X

InterchangeAcknowledgement(TA1)

.TA1 X X X X X

InterchangeAcknowledgement -Readable (TA1)

.TAT X X X X X

ImplementationAcknowledgement(999)

.999 X X X X X

ImplementationAcknowledgement-Readable (999)

.99T X X X X X

Immediate BatchResponse-PipeDelimited Data

.ibr X

Immediate BatchResponse-ReadableReport

.ibt X

Electronic BatchReport-PipeDelimited Data

.ebr X

Electronic BatchReport-ReadableReport

.ebt X

Delayed PayerReport 1

.dpr X

1 Received from selected payers onlyOctober 2020 005010 | of 105© Availity, LLC, all rights reserved | Confidential and proprietary.


File name Extension 837 835 270/271 276/277 278/278 278N/278N

Delayed PayerReport

.dpt X

Health CareServices ReviewSummary TextReport

.278ebr X X

ElectronicRemittance Advice

.era X

X12 PairedResponseTransaction

.271 X


.277 X


.278 X


.278N X



Response file and ERA file naming conventions

Response file naming conventions

File type Naming convention

File Acknowledgement (ACK) <<Availity Batch ID>>.ACK

File Acknowledgement-Readable (ACT) <<Availity Batch ID>>.ACT

Interchange Acknowledgement (TA1) <<Availity Batch ID>>.TA1

Interchange Acknowledgement-Readable (TAT) <<Availity Batch ID>>.TAT

Implementation Acknowledgement (999) <<Availity Batch ID>>.999

Implementation Acknowledgement-Readable(99T)

<<Availity Batch ID>>.99T

Immediate Batch Response (IBR) IBR-<<CCYYMMDDHHMM>>-<<SEQ#>>.ibr

Immediate Batch Response-Readable (IBT) IBT-<<CCYYMMDDHHMM>>-<<SEQ#>>.ibt

Health care claim acknowledgement - 277CA(277IBR)

277CA-<<CCYYMMDDHHMMSS>>-<<SEQ#>>.277ibr




Electronic Batch Report (EBR) One of the following based on selected groupingoption:

All responses for an organization by payer

Default: EBR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>.ebr

All responses for an organization, multiplepayers

EBR-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>.ebr

All responses for a provider by payer

• EBR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>.ebr

• EBR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>-<<NPI>>.ebr

All responses for a provider, multiple payers

• EBR-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>.ebr

• EBR- MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>-<<NPI>>.ebr




Electronic Batch Report-Readable (EBT) One of the following based on selected groupingoption:


Default: EBT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>.ebt


EBT-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>.ebt


• EBT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>.ebt

• EBT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>-<<NPI>>.ebt


• EBT-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>.ebt

• EBT- MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>-<<NPI>>.ebt

Health care claim acknowledgement - 277CA(277EBR)

277CA-<<CCYYMMDDHHMMSS>>-<<SEQ#>>.277ebr




Delayed Payer Report (DPR) One of the following based on selected groupingoption:


Default: DPR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>.dpr


DPR-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>.dpr


• DPR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>.dpr

• DPR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>-<<NPI>>.dpr


• DPR-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>.dpr

• DPR- MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>-<<NPI>>.dpr




Delayed Payer Report-Readable (DPT) One of the following based on selected groupingoption:


Default: DPT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>.dpt


DPT-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>.dpt


• DPT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>.dpt

• DPT-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<seq#>>-<<TaxID>>-<<NPI>>.dpt


• DPT-MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>.dpt

• DPT- MULTIPAYER-<<CCYYMMDDHHMM>>-<<seq#>>-<<Tax ID>>-<<NPI>>.dpt

Health care claim acknowledgement - 277CA(277DPR)

277CA-<<CCYYMMDDHHMMSS>>-<<SEQ#>>.277dpr

Eligibility Benefit Response (271) One of the following based on selected groupingoption:

• Default: 271-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.271

• 271-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<2100B NM109>>.271




Claim Status Response (277) One of the following based on selected groupingoption:



Health Care Services Review Response (278) One of the following based on selected groupingoption:



Health Care Services Review Notification andAcknowledgement (278N)

One of the following based on selected groupingoption:

• Default: 278N-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.278N

• 278N-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<2100B NM109>>.278N

Health Care Services Review Summary TextReport (278ebr)

One of the following based on selected groupingoption:

• Default: 278EBR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.278ebr

• 278EBR-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<2100B NM109>>.278ebr

Legend:

• <<Availity Batch ID>> – Availity assigned

• <<CCYYMMDDHHMM>> – Date-time stamp

• <<Payer Short Name>> – Representation of payer full name, up to 10-bytes

• <<SEQ#>> – 3-byte sequence number starting at ‘001' and incrementing by 1 for each file within sameCCYYMMDDHHMM



ERA file naming conventions

Grouping option Naming convention

One check per file ERA-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.era

Example:

ERA-BCBS_OF_FL-200902201240-001.era

All checks destined for an organization by payer

Note: This method is the default setting for allcurrent 835 recipients.

ERA-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.era

Example:

ERA-BCBS_OF_FL -200902201240-001.era

All checks for an organization from multiplepayers

ERA-MULTIPAYER-<<CCYYMMDDHHMM>>-<<SEQ#>>.era

Example:

ERA-MULTIPAYER-200902201240-001.era

All checks for a provider by payer, and whereevery check in the file bears the same tax ID, butnot the same NPI or the NPI is missing

ERA-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<TaxID>>.era

Example:

ERA-BCBS_OF_FL-200902201240-001-987654321.era

All checks for a provider by payer, and whereevery check in the file bears the same tax ID andsame NPI

ERA-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<TaxID>>-<<NPI>>.era

Example:

ERA-BCBS_OF_FL-200902201240-001-987654321-1234567890.era

All checks for a provider by payer, and where atleast two different tax IDs appear in the file

ERA-<<Payer Short Name>>-<<CCYYMMDDHHMM>>-<<SEQ#>>.era

Example:

ERA-BCBS_OF_FL-200902201240-001.era



Grouping option Naming convention

All checks for a provider from multiple payers • If there is a Tax ID in the file, the convention isas follows:

ERA-MULTIPAYER-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<Tax ID>>.era

Example:

ERA-MULTIPAYER-

200902201240-001-987654321.era

• If there isn't a Tax ID in the file, the NPI is usedin place of the Tax ID, and the convention is asfollows:

ERA-MULTIPAYER-<<CCYYMMDDHHMM>>-<<SEQ#>>-<<NPI>>.era

Legend:

• <<CCYYMMDDHHMM>> – Date-time stamp

• <<Payer Short Name>> – Representation of payer full name, up to 10-bytes

• <<SEQ#>> – 3-byte sequence number starting at ‘001' and incrementing by 1 for each file within a setof files that otherwise would have the same name. Sequence numbers are generated for ERA filesunder the following conditions:

• When the system creates additional ERA files to accommodate checks that exceed the user-defined file size limit.

• When the user selects the 'one check per file' aggregation method and the date-time stamp on theresulting files is the same.

• When the user selects the 'all checks for a provider by payer' aggregation method and the samedate-time stamp, payer short name, and ID combination occurs for multiple files.

• <<Tax ID>> – The federal tax ID for the pay-to provider named in the checks.

• <<NPI>> – The NPI for the pay-to provider.

Note:

• ERA files from BCBSIL, BCBSNM, BCBSOK and BCBSTX are not aggregated with other ERAs, nordo they follow the naming convention described above. Rather, all of their ERA files include the .835file extension, which may or may not be followed by additional characters, as in the following example:

XXXXXXX.835.XXX_XX_XXXXXX_XXXX

• If you choose to receive compressed files, the ERAs are contained in a ZIP file with file extension.zip.



Notification fileWhen a submitted batch file is received, Availity attempts to recognize the file by validating the followingcriteria:

• File contains content

• Acceptable file type

• Acceptable file format, identified by ISA in first three bytes

Batch file accepted by AvailityIf an error does not occur at this point, the next step in validation begins and a notification file, indicatingsuccess, is delivered to the SendFiles folder. The name of the notification file is the name of the originalbatch file, concatenated with the Availity batch ID that was assigned to the file, and the suffix -success.The batch ID is simply the date/time that the file was submitted.

Figure 1: Example: -success file (batch file submitted through browser)

Tip: If you submitted the batch file through a browser, you can delete the notification file from theSendFiles folder by clicking the trash can icon in the Delete column of the file you want.

Batch file rejected by AvailityIf an error occurs at this point, Availity does not process the batch file any further. A notification file,containing an error message, is delivered to the SendFiles folder. The name of the notification file is thename of the original batch file, concatenated with the Availity batch ID that was assigned to the file, andthe suffix -FAILED. The batch ID is simply the date/time that the file was submitted.

To view the reason for the failure, do one of the following:

• If you submitted the batch file through an FTP client, use the tools in your software to open the -FAILED file, to view the errors.



• If you submitted the batch file through Availity Portal or via FTP through a browser, click the tools

icon in the File Options column of the file you want, and then click a download option such astext/plain, under Download and Delete Files. You can also download the file directly through yourbrowser.

When a failed file upload occurs, one of the following error messages displays in the -FAILED file:

Empty file received - please review and resubmit

• Cause – This error occurs when the transmission file has zero bytes (is empty).

• Troubleshooting – Rebatch the file in your PMS, HIS, or other system using a new interchangecontrol number (ICN), and then resubmit it, ensuring the file contains data. If the problem occurs againwith the rebatched transmission file, contact your vendor. Your system may be creating files incorrectly.

Invalid file type received - please review and resubmit

• Cause – This error occurs when the transmission file is not atext (.txt) file. It may contain one of these incorrect file extensionsinstead: .exe, .jpg, .tif, .tiff, .emf, .jpeg, .jff, .jpe, .png, .bmp, .bid, .rle, .bmz, .gif, .gfa, .wpg.

• Troubleshooting – Rebatch the transmission file in your PMS, HIS, or other system using a newinterchange control number (ICN) and the extension .txt. If you are certain the file is a text file, butmerely contains the wrong extension, you can change the file extension manually to .txt withoutrebatching it. Then resubmit the file. If the problem occurs again with the rebatched file, contact yourvendor. Your system may be applying an incorrect file extension.

Invalid file format received - please correct and resubmit

• Cause – This error occurs when the first three bytes in a transmission file are not ISA.

• Troubleshooting – Rebatch the transmission file in your PMS, HIS, or other system using a newinterchange control number (ICN). Ensure the first three bytes contain ISA, and then resubmit it. Ifthe problem occurs again with the rebatched file, contact your vendor. Your file may contain controlcharacters that are not viewable in text format or your system may be creating files incorrectly.



File acknowledgement (ACK)Availity automatically sends a negative file acknowledgement (ACK) to your organization's ReceiveFilesfolder when a submitted batch file fails Availity's proprietary validation, most commonly when the fileformat is invalid.

File extensions

• .ACK (delimited file)

• .ACT (human readable text file) – This is the default format.

When is this response file sent?

Within 24 hours, and only if errors occur.

• Negative file acknowledgements are not optional.

• Positive file acknowledgements are not sent.

If you do not receive the acknowledgement, please contact Availity Client Services.

Additional details

This response file reports errors in acceptable file format. The following criteria are validated:

• The first three characters in the file are ISA.

• The ISA segment is valid.

Next steps

When a file acknowledgement (ACK) is generated, processing of the batch file terminates. You mustcorrect and resubmit the entire batch.

Example: File Acknowledgement

1|2020-07-15|12.06.05.726||2009031511593700|3003005571E|Availity does not recognize the interchange data starting at position 0 as valid.



Interchange acknowledgementAvaility automatically sends negative interchange acknowledgements to your organization's ReceiveFilesfolder. This file reports errors encountered within the interchange header or trailer of the X12 file,particularly errors caused by duplicate interchange control numbers or an incorrect trading partnerenvelope.

File extensions

• .TA1 (X12 file) – This is the default format.

• .TAT (human readable text file)



• Negative interchange acknowledgements are not optional.

• To receive positive interchange acknowledgements, the value of ISA14 must be set to 1 in thesubmitted batch file. Positive interchange acknowledgements are returned with the implementationacknowledgement file (999).

Additional details

This response file reports errors (TA104) in the interchange control header (ISA) or trailer (IEA). Thefollowing criteria are validated:

• Duplicate interchange control number (ISA13).

• Incorrect trading partner envelope, signified by an invalid value in either the interchange controlheader (ISA) or functional group header (GS) segments.

Next steps

When an interchange acknowledgement is generated, processing of the batch file terminates. You mustcorrect and resubmit the entire batch.



Interchange acknowledgement - format and examples

Elements on the TA1 segment

Field Description HIPAA segment ID

Interchange Control Number • Required


TA101

Interchange Date • Required

• Format: YYMMDD

TA102

Interchange Time • Required

• Format: HHMM

TA103

Interchange AcknowledgementCode

• Required


TA104

Interchange Note Code • Required


TA105

Example: Interchange Acknowledgement (TA1)

ISA*00* *00* *01*030240928 *ZZ*AV09311993 *190103*1440*^*00501*185486211*0*T*:~TA1*219381897*181207*2204*R*025~IEA*0*185486211~

Example: Human readable Interchange Acknowledgement (TAT)

AVAILITY TA1 INTERCHANGE ACKNOWLEDGEMENT

Customer ID: 0002176 File Status: ACCEPTEDDate Received: 2010-12-07 Time Received: 11:58:26.137Filename: RespReport_test3.TXTFile Control Number: 000164875*************************************************************************************************************Interchange acknowledged: TA101**********************************************************************************************************************************Interchange Date: 101201 Interchange Time: 0933Interchange Status: AInterchange Note: 000------------------------------------------------------------------------------------------------------------- END OF REPORT-------------------------------------------------------------------------------------------------------------



Implementation acknowledgementAvaility automatically sends negative implementation acknowledgements to your organization'sReceiveFiles folder. This file indicates that Availity received the transmission file and it had errors,particularly X12 and HIPAA syntax errors. Implementation acknowledgements are also referred to as 999files.

File extensions

• .999 (X12 file) – This is the default format.

• .99T (human readable text file)



• Negative implementation acknowledgements are not optional.

Additional details

The X12N EDI standard 999 Implementation Acknowledgement transaction (.999) is used to report theacceptance or rejection of each transaction set (ST/SE) within each functional group (GS/GE) containedin the inbound file of ASC X12N 5010 EDI transactions.

• Negative implementation acknowledgement - If the entire file does not pass the validation,AvailityAvaility rejects it entirely and sends a negative implementation acknowledgement (999) to yourorganization's ReceiveFiles mail box. The file is not processed further, and the transactions are notrouted to the payer. IK501 and AK901 = R.

• Partial implementation acknowledgement - If the file contains multiple transaction sets and someof them pass validation and others do not, Availity partially rejects the file. This means that Availityrejects or accepts the file at the transaction-set level. For partially rejected files, Availity sends animplementation acknowledgement (999) to your organization's ReceiveFiles mail box. Rejectedtransaction sets are not processed further, and they are not routed to the payer. Accepted transactionsets continue through processing. IK501=R and AK901 = P.

• Positive implementation acknowledgement - If the entire file passes validation in this step and youset up your EDI reporting preferences to receive positive implementation acknowledgements (999),Availity sends a positive acknowledgement file to your organization's ReceiveFiles mail box. Theaccepted transaction sets proceed to the next step in processing. IK501 and AK901 = A.

• If the file contains multiple ISA/IEA segments, Availity sends an acknowledgement for each ISA/IEApairing.



Next steps

If Availity rejects or partially rejects any or all transaction sets, you must correct the errors in your EDIbilling system, rebatch all transactions in the rejected transaction sets, and upload the new file to Availityagain.

Important: You must rebatch even those transactions in the rejected transaction set that do not needcorrection, because as part of the rejected transaction set, they have not been routed to the payer yet.Also, you must upload the corrected transaction sets using a new interchange control number (ICN). Ifyou attempt to upload them using the previous interchange control number, Availity rejects the file as aduplicate.

Implementation acknowledgement 999 - format and examples

Implementation acknowledgement 999 format

837 claim 999 acknowledgement

ISA GS - 837 ST *837*0001 SE ST *837*0002 SE GE

GS - 837 ST *837*0001 SE GEIEA

ISA GS – 999 ST AK1(AK102 equals GS06 in the functional group being acknowledged) AK2 (AK202 equals ST02 in the transaction set being acknowledged) IK5 AK2 (AK202 equals ST02 . . .) IK5 AK9 SE GE GS ST AK1 (AK102 equals GS06 . . .) AK2 (AK202 equals ST02 . . .) IK5 AK9 SE GE IEA

Detail implementation specifications for the 999 Implementation Acknowledgement can also be found inthe Implementation Acknowledgment For Health Care Insurance.



As shown in the following examples, the 999 transaction is intended to be imported into an automatedsystem such as an EDI X12N compatible practice management system, and therefore is not formatted forhuman readability. A human-readable version is provided by the 99T format.

Example: 999 file rejected

ISA*00* *00* *01*030240928 *ZZ*AV09311993*031204*1109*U*00501*000090091*0*P*:~TA1*000001732*031204*1101*A*000~GS*FA*030240928*AV01101957*20031204*1109*80180*X*005010X231A1~ST*999*0001*005010X231A1~AK1*HC*17321*005010X223A2~AK2*837*000000001*005010X223A2~IK3*CL1*24*2300*8~CTX*CLM01:393931D_1310~IK4*2*1314*5*AA~IK5*R*5~AK9*R*1*1*0~SE*8*0001~GE*1*80180~IEA*1*000090091~

Example: 999 file accepted

ISA*00* *00* *01*030240928 *ZZ*AV09311993*030306*1356*U*00501*000000000*0*P*:~GS*FA*030240928*AV01101957*20030306*1356*000000000*X*005010X231A1~ST*999*000000000*005010X231A1~AK1*HC*103136*005010X222A1~AK2*837*000003136*005010X222A1~IK5*A~AK9*A*1*1*1~SE*6*000000000~GE*1*000000000~IEA*1*000000000~



Implementation acknowledgement 99T - readable format

The 99T format of the 999 Implementation Acknowledgement provides the same information as theX12 format of the 999 acknowledgement, but in a readable format. Like the X12 version, it reports theacceptance or rejection of each transaction set (ST/SE) within each functional group (GS/GE) containedin the inbound file of ASC X12N 5010 EDI transactions.

The following figure shows an example of the Availity 999 Implementation Acknowledgement in itsreadable format.



Immediate batch responseThe immediate batch response (also referred to as an IBR) is a proprietary report that acknowledgesaccepted claims and identifies rejected claims due to HIPAA edits and payer-specific edits (PSEs) thatAvaility conducted on behalf of payers. The report also includes claim counts and charges at the claimlevel and file level. Only claims that passed file format and syntax validations are included in this report.

File extensions

• .IBR (delimited file) – This is the default format.

• .IBT (human readable text file)

• .277IBR – 277CA claim acknowledgement format.


Within minutes after transmission or up to 24 hours depending upon the volume of claims processing atthat time.

• Immediate batch responses are sent only for claims, not non-claim transactions.

• This is an optional response file.

Additional details

• Availity generates the IBR after an accepted (A), accepted with errors (E), or a partial accepted (P)Implementation Acknowledgement (999) has been posted to your ReceiveFiles mailbox.

• If any errors display in this report, you can correct the claims, rebatch them, and resubmit them. Thisresponse file benefits you because it allows you to correct problems without having to wait for thepayer to finish processing the rest of the transmission file.

• Unless your administrator selected grouping options, each IBR represents one ISA – IEA. If a filecontains multiple ISA – IEA, Availity generates an IBR for each ISA – IEA.

• Rejected claims on the IBR also appear as rejected claims on the electronic batch report (EBR).

• Availity does not generate or return an IBR in the following situations:

• If the complete batch file rejected on a negative ACK, TA1 or 999 file.

• If the batch file contained non-claims transactions (27x.).

Next steps

For every claim identified as rejected in the IBR, you must correct the errors in your EDI transactionssystem or practice management system, rebatch the claims with a new interchange control number, andupload the new file to Availity again. Claims that contain no HIPAA-compliance errors or payer-specificerrors are routed to the payer.



Immediate Batch Response (IBR) - pipe delimited format

The pipe-delimited IBR file provides claim detail for all claims within the file (accepted and rejected) and isintended to be imported into an automated system.

Immediate Batch Response (IBR) layout

1│CCYY-MM-DD - Date Received│HH.MM.SS.SSS - Time Received│blank - Internal Use Only│CCYYMMDDXXXXXXXX - Availity Batch ID (assigned by Availity)│Inbound ISA13 value - File Control Number│99999 - Total Submitted Claims│000000.00 - Total Submitted Charges│00000 - Total Accepted Claims│ 000000.00 - Total Accepted Charges │00000 - Total Rejected Claims│0000.00 Total Rejected Charges│Availity Messages│Availity Customer ID| Availity File ID | Original File Name |2│Payer Name│NA│ NA│NA│ NA│ NA│NA│Payer ID│3│Patient Last Name, First Name│CCYYMMDD - From Date │CCYYMMDD - To Date│Echo inbound CLM01 - Patient Control Number│00000.00 – Echo inbound CLM02 Total Claim Charge │Provider Billing ID – 2010AA, NM109│ Clearinghouse Trace # │NA│Availity Trace # (will be NA in the IBR)│Submitter Batch ID│"I", "W, "A" or "R" - Status |3e│Error Initiator│R│Error Code – if available, otherwise NA│Error Message | Loop│Segment ID│Element # ││││ Version |

Note:

• Line 1 will occur once per ISA.

• Line 2 will occur for every payer within the ISA.

• Line 3 will occur once per claim for a payer.

• Line 3e will occur if the claim is rejected by an Availity, HIPAA or Payer Specific Edit (PSE). Multiple 3elines per claim can occur.

• If no error message number is available, field 3 will equal NA.

Sample report structure

Line 1 (ISA Level) Line 2 (Payer 1 Level Claim Rejects/Accepts) Repeat > 1 Rejects = > Line 3 (Claim Level) Repeat > 1 Line 3e (Claim Level Error) Repeat > 1 Accepts => Line 3 (Claim Level) Repeat > 1 Line 2 (Payer 2 Level Claim Rejects/Accepts) Repeat > 1 Rejects => Line 3 (Claim Level) Repeat > 1 Line 3e (Claim Level Error) Repeat > 1 Accepts => Line 3 (Claim Level) Repeat > 1 Repeat by payer…..

Example: Immediate Batch Response (IBR)

1|2010-08-17|15.26.05.222|NA|2017092718492800|000001869|18|3829.00|15|2954.00|3|875.00|NA|0001815|1-41025630|UHCtext.txt|2|UNITED HEALTHCARE (UHC)|NA|NA|NA|NA|NA|NA|87726|3|DUCK, DON|20170927|20170927|123456|336.00|1760438840|NA|NA|NA|1464|R|3e|HIPAA|R|3938ed5|Claim balancing is failed: total charge amount (CLM02) '336.00' does not equal sum of line charge amounts (SV102) '337.00'. Segment CLM is defined in the guideline at position 130. Invalid data: 336|2300|CLM|02||||5010|2|CIGNA|NA|NA|NA|NA|NA|NA|12345|3|STAR, RINGO|20170927|20170927|888|230.00|1760438840|NA|NA|128799450_1|1464|A|3|KEYS, PIANO|20170927|20170927|856301|210.00|1760438840|NA|NA|128799450_2|1464|A|3|CHILDS, JULIA|20170927|20170927|856320|337.00|1760438840|NA|NA|NA|1464|R|3e|HIPAA|R|3939612|HCPCS Procedure Code is invalid in Professional Service. Invalid data: 90772|2400|SV1|01||||5010|2|HUMANA|NA|NA|NA|NA|NA|NA|87726|3|SMART, PHONE|20170927|20170927|850043|174.00|1760438840|NA|NA|128799450_4|1464|A|3|JUNGLE, JIM|20170927|20170927|899935|117.00|1760438840|NA|NA|128799450_5|1464|A|



3|POP, MUSIC|20170927|20170927|8594|202.00|1760438840|NA|NA|128799450_6|1464|A|

Immediate batch response (IBT) - readable format

The IBT format of the Immediate Batch Response report provides the same information as the pipe-delimited format, but in a readable format. Like the pipe-delimited version, it provides claim detail for allclaims within the file (accepted and rejected).

Immediate Batch Response (IBT) layout

Availity Customer ID: <<0>> Immediate Batch Text Response Availity Messages: <<1>>---------------------------------------------------------------------------------------- BATCH SUMMARYDate Received: <<2>> Time Received: <<3>>Availity Batch ID: <<4>> File Control Number: <<5>> ISA #1Availity File ID: <<6>>File Name: <<7>>Submitted Claims: <<8>> Total Submitted Charges: <<9>>Accepted Claims: <<10>> Total Accepted Charges: <<11>>Rejected Claims: <<12>> Total Rejected Charges: <<13>>----------------------------------------------------------------------------------------Payer Name: Payer #1 <<14>> Payer ID: <<15>>----------------------------------------------------------------------------------------Submitter Batch ID: <<16>> Status: <<17>>Patient Name: <<18>> Patient Control Number: <<19>>From Date: <<20>> To Date: <<21>> Charge: <<22>> Provider Billing ID: <<23>>Clearinghouse Trace #: Claim #1 Availity Trace #: <<25>>Error Initiator: <<26>> Loop: <<27>>Segment ID: <<28>> Element #: <<29>>Error Message: <<30>> Version: <<31>>----------------------------------------------------------------------------------------Submitter Batch ID: <<16>> Status: <<17>>Patient Name: <<18>> Patient Control Number: <<19>>From Date: <<20>> To Date: <<21>> Charge: <<22>> Provider Billing ID: <<23>>Clearinghouse Trace #: Claim #2 Availity Trace #: <<25>>Error Initiator: <<26>> Loop: <<27>>Segment ID: <<28>> Element #: <<29>>Error Message: <<30>> Version: <<31>>----------------------------------------------------------------------------------------Payer Name: Payer #2 <<14>> Payer ID: <<15>>----------------------------------------------------------------------------------------Submitter Batch ID: <<16>> Status: <<17>>Patient Name: <<18>> Patient Control Number: <<19>>From Date: <<20>> To Date: <<21>> Charge: <<22>> Provider Billing ID: <<23>>Clearinghouse Trace #: Claim #3 Availity Trace #: <<25>>Error Initiator: <<26>> Loop: <<27>>Segment ID: <<28>> Element #: <<29>>Error Message: <<30>> Version: <<31>>----------------------------------------------------------------------------------------



---------------------------------------------------------------------------------------- BATCH SUMMARY Date Received: <<2>> Time Received: <<3>>Availity Batch ID: <<4>> File Control Number: ISA #2Availity File ID: <<6>>File Name: <<7>>Submitted Claims: <<8>> Total Submitted Charges: <<9>>Accepted Claims: <<10>> Total Accepted Charges: <<11>>Rejected Claims: <<12>> Total Rejected Charges: <<13>>----------------------------------------------------------------------------------------Payer Name: Payer #1 <<14>> Payer ID: <<15>>----------------------------------------------------------------------------------------Submitter Batch ID: <<16>> Status: <<17>>Patient Name: <<18>> Patient Control Number: <<19>>From Date: <<20>> To Date: <<21>> Charge: <<22>> Provider Billing ID: <<23>>Clearinghouse Trace #: Claim #4 Availity Trace #: <<25>>Error Initiator: <<26>> Loop: <<27>>Segment ID: <<28>> Element #: <<29>>Error Message: <<30>> Version: <<31>>----------------------------------------------------------------------------------------Payer Name: Payer #21 <<14>> Payer ID: <<15>>----------------------------------------------------------------------------------------Submitter Batch ID: <<16>> Status: <<17>>Patient Name: <<18>> Patient Control Number: <<19>>From Date: <<20>> To Date: <<21>> Charge: <<22>> Provider Billing ID: <<23>>Clearinghouse Trace #: Claim #5 Availity Trace #: <<25>>Error Initiator: <<26>> Loop: <<27>>Segment ID: <<28>> Element #: <<29>>Error Message: <<30>> Version: <<31>>---------------------------------------------------------------------------------------- END OF REPORT --------------------------------------------------------------------

Descriptions of fields in the IBT layout

Field number Field Note

0 Availity Customer ID Entity customer ID

1 Availity Messages NA - at this time

2 Date Received CCYY-MM-DD

3 Time Received HH.MM.SS.SSS

4 Availity Batch ID File name assigned by Availity:INTERNAL_FILENAME

5 File Control Number ISA13:

6 Availity File ID Availity assigned -DB_INSTANCE_NUM<->DOCUMENT_SEQ

Example: 1-123456789

7 File Name Original incoming file name:EXCHANGE_FILENAME




8 Submitted Claims Count of 2300 CLM per ISA

9 Total Submitter Charges Sum of all 2300 CLM02;9,999.99 format

10 Accepted Claims Count of 2300 CLM acceptedper ISA

11 Total Accepted Charges Sum of accepted 2300 CLM02;9,999.99 format

12 Rejected Claims Count of 2300 CLM rejected

13 Total Rejected Charges Sum of rejected 2300 CLM02,9,999.99

14 Payer Name Availity payer name |UNKNOWN

15 Payer ID 2010BB NM109 (professional) |2010BC NM109 (institutional)

16 Submitter Batch ID BHT03

17 Status A | R | W | I

18 Patient Name 2010BA/CA NM103, NM104

19 Patient Control Number 2300 CLM01

20 From Date 2400 DTP03 | 2300 DTP03;CCYYMMDD format

21 To Date 2400 DTP03 | 2300 DTP03;CCYYMMDD format

22 Charge 2300 CLM02; 9,999.99 format

23 Provider Billing ID 2010AA NM109

24 Clearinghouse Trace # 2300 REF02 from inboundsubmitter REF*D9 | NA

25 Availity Trace # Outbound REF*D9 | NA – Forthe rejected claims, this willalways be NA in the IBT/IBR.




26 Error Initiator Availity | PSE | HIPAA – Weuse the 'Availity' value when wereject for unrecognized payer orsubmission of a test file in theproduction environment.

27 Loop Loop ID

28 Segment ID Segment ID

29 Element # Element number

30 Error Message Detailed claim error message

31 Version 5010

Note:

• Detailed error messages display. The error message field wraps within the allotted byte length 88.

• All fields containing monetary amounts (currency) will follow U.S. currency format standards.

• The currency format display includes commas denoting thousands of dollars.

• The currency format display includes two decimal places denoting cents.

Example: Immediate Batch Response (IBT)



277IBR Examples

Example: 277CA Positive Immediate Batch Response (IBR)

ISA*00* *00* *01*030240928 *ZZ*AV09311993 *110517*1305*^*00501*000356253*0*T*:~GS*HN*030240928*AV01101957*20110517*1305*356254*X*005010X214~ST*277*1001*005010X214~BHT*0085*08*356255*20110517*130522*TH~HL*1**20*1~NM1*AY*2*AVAILITY LLC*****46*030240928~TRN*1*20110517130522167~DTP*050*D8*20110517~DTP*009*D8*20110517~HL*2*1*21*1~NM1*41*2*AVAILITY LLC*****46*030240928~TRN*2*239097104~STC*A1:20*20110517*WQ*259.5~QTY*90*1~AMT*YU*259.5~HL*3*2*19*1~NM1*85*2*PROVIDER*****XX*1234567890~TRN*1*0~QTY*QA*1~AMT*YU*259.5~HL*4*3*PT~NM1*QC*1*LASTNAME*FIRSTNAME****MI*K11111~TRN*2*TEST00013537401~STC*A1:20*20110517*WQ*259.5~REF*D9*239097104_16~DTP*472*RD8*20100831-20100831~SE*25*1001~GE*1*356254~IEA*1*000356253~

Example: 277CA Negative Immediate Batch Response (IBR)

ISA*00* *00* *01*030240928 *ZZ*AV09311993 *110524*1645*^*00501*000448848*0*T*:~GS*HN*030240928*AV01101957*20110524*1645*448849*X*005010X214~ST*277*1001*005010X214~BHT*0085*08*448850*20110524*164536*TH~HL*1**20*1~NM1*AY*2*AVAILITY LLC*****46*030240928~TRN*1*2011052416453672~DTP*050*D8*20110524~DTP*009*D8*20110524~HL*2*1*21*1~NM1*41*2*AVAILITY LLC*****46*030240928~TRN*2*239745576~STC*A1:20*20110524*WQ*75~QTY*AA*1~AMT*YY*75~HL*3*2*19*1~NM1*85*2*PROVIDER*****XX*1154374825~TRN*1*0~REF*TJ*561853990~QTY*QC*1~AMT*YY*75~HL*4*3*PT~NM1*QC*1*LASTNAME*FIRSTNAME****MI*W1234567890~TRN*2*110549~STC*A3:448*20110524*U*75********TRANSACTION SET HEADER IS INVALID. INVALID DATA 005010X222~REF*D9*239745576_0~DTP*472*RD8*20101001-20101001~SE*26*1001~GE*1*448849~IEA*1*000448848~



Electronic batch reportThe electronic batch report (also referred to as an EBR) is a proprietary report that provides the status(received from the payer) for each transaction in the original submission. The report contains summarycounts of transactions received and accepted, and lists detailed information for rejected transactions,including payer specific edits (PSEs) and HIPAA edits. Only claims that passed file format and syntaxvalidations are included in this report.

File extensions

• .EBR (delimited file)

• .EBT (human readable text file) – This is the default format.

• Summary report (errors and prepayment responses) – This is the default report.

• Detail report (all claims acknowledged)

• .277EBR – 277CA claim acknowledgement format.

Note: The .277EBR can only be received in combination with the .EBR or .EBT.


When all expected responses are received from the payer; typically within 24-48 hours. If a payer failsto send any response within five business days, Availity contacts the payer to obtain a status on thetransaction set.

• Electronic batch reports are sent only for claims, not non-claim transactions.


Additional details

• Batches and/or claims received with an invalid or unrecognized payer will generate the standard EBRreport. The impacted claims display in the rejected claims section of the EBR.

• Information returned on accepted claims includes the following: patient name, claim service dates,patient control number, charge, provider billing id, clearinghouse trace number, payer claim number,Availity trace number, the message source (usually the payer name), and any message codes andmessage text.

• If the payer does NOT normally send a claim response, but sends a positive acknowledgement,indicating it has received the claims and found no errors during any file processing performed bythis point, Availity sends the EBR containing the Availity validation information to your organization'sReceiveFiles mail box. Payers unable to return a claim response, such as some small payers, fall intothis category and are referred to as "999-only payers."

• If the payer normally sends a claim response, Availity waits for the claim response for all claims inthe file from the payer, and then compiles the information into the EBR with the Availity validationinformation and sends it to your ReceiveFiles mail box.

• Uncommonly, a payer may send a negative acknowledgement, meaning it has found errors in thetransaction sets during validation. In this case, Availity contacts the payer to determine the cause ofthe error. If the error requires you to fix and resubmit the transaction sets, Availity contacts you (theprovider) to discuss the issue.



• Because Availity generates a response file for each payer in each transaction set, you might receivemultiple response files for a single file, and you probably won't receive them all at the same time. Ifyou need to change the delivery times of the response files, contact your administrator to adjust thedelivery options for electronic batch reports.

• Sometimes claims are routed to the payer through other clearinghouses or intermediaries, who alsoperform validations on the claims. These additional validations are the reason you might receive anerror in the EBR stating a claim was rejected at another clearinghouse even though you submitted itthrough Availity.



Next steps

Monitor status of transactions, correct and resubmit transactions with errors.

If the payer rejects any transactions (claims) at this stage (identified by the payer's name in the ErrorInitiator field), you must correct and rebatch the rejected claims in your system using a new interchangecontrol number (ICN), and then upload and resubmit a new file.

Note: You do not need to include accepted claims in the new file, since those claims have already beenprocessed and accepted at the payer level. Also, if you already corrected and rebatched any rejectedclaims identified in the IBR, you do not need to do it again, although those errors may display in the EBRwith either HIPAA or Availity in the Error Initiator field.

Electronic Batch Report (EBR) - pipe delimited format

The pipe-delimited EBR file is intended to be imported into an automated system.

Electronic Batch Report (EBR) layout

1│Date of Batch Receipt – CCYY-MM-DD│Time of Batch Receipt- HH.MM.SS.SSS│Internal Usage│Availity Batch ID│File Control Number│Availity Customer ID│Availity File ID │Original File Name|||

2│Payer Name – from Availity Payer File│Claim Responses Returned│ Total Accepted Claim Count│Total Claim Responses Returned Charges│Total Accepted Claim Charges│Total Rejected Claim Count│Total Rejected Claim Charges│Payer ID|

3│Patient Last Name, First Name│From Service Date - CCYYMMDD│To Service Date - CCYYMMDD│Patient Control Number│Total Claim Charges │Billing Provider ID│ Clearinghouse Trace Number │Payer Claim Number or NA │Availity Trace Number││

3e│Error Initiator│R│Error Code – if available, otherwise NA│Error Message | Loop│Segment ID│Element # ││││ Version |

3a│Bill Type│Allowed Amount│Non-Covered Amount │Deductible Amount │Co-Pay Amount │Co-insurance Amount │Withhold Amount │Estimated Payment Amount │Patient Liability│Message Code│Message Text│

3c│Error Initiator | Message Type│ Error Code |Error Message | Loop│Segment ID │ Element # │



Note:

• Line 1 is the file/ISA level.

• Line 2 is the payer level.

• Line 3 will occur once per claim. Line 3 will always have a line 3e, 3a, or 3c following. All 3/3e lines willoccur first followed by all 3/3a lines, followed by all 3/3c lines.

• Line 3e will occur minimum of once for each Availity, HIPAA or PSE reject. Multiple 3e lines per claimcan occur.

• Line 3a will occur if a claim is accepted by both Availity and the Receiver and the payer returnsadjudication information in their response file.

• Line 3c indicates a clean claim without adjudication information. Line 3c will occur if a claim isaccepted by both Availity and the receiver and there is no adjudication information.

Example 1: Electronic Batch Report (EBR)

1|2010-08-27|14.05.33.434|NA|2010082713594600-UPL|008271053|0060000|||2|MEDICARE B - TEXAS|2|2|200.00|200.00|0|0.00|04402|3|DUCK, DONALD|20100728|20100728|1218|100.00|1457382525|NA|NA|230038742_0||3c|TRAILBLAZER|NA|NA|This claim has been accepted for further processing|NA|NA|NA|3|MOUSE, MINNIE|20100707|20100707|1262|100.00|1457382525|NA|NA|230038742_1||3c|TRAILBLAZER|NA|NA|This claim has been accepted for further processing|NA|NA|NA|

1|2010-08-31|12.56.06.182|NA|2010083112541900|369998138|0001815|||2|Arkansas BCBS|1|0|75.00|0.00|1|75.00|00520|3|DOE, JOHN|20091019|20091019|GOOKA000|75.00|1225057391|155835019_0|NA|NA||3e|HIPAA|R|3938ed5|Claim balancing is failed: total charge amount (CLM02) '75.00' does not equal sum of line charge amounts (SV102) '76.00'. Segment CLM is defined in the guideline at position 130. Invalid data: 75|2300|CLM|02||||

Example 2: Electronic Batch Report (EBR)

1|2010-12-07|11.58.23.023|NA|2010120711582200|000164875|0002176|2010120711582200|RespReport_test3.TXT|||2|HUMANA|2|0|290.00|0.00|2|290.00|61101|3|SMITH, JADA|20101105|20101105|16386|165.00|9876543213|467484130|NA|27080||3e|HUMANA|R|42|Invalid use of Null|NA|NA|NA||||5010|3|WOMAN, WONDER|20101107|20101107|16386|125.00|9876543213|467484132|NA|27081||3e|HUMANA|R|42|Invalid use of Null|NA|NA|NA||||5010|



Electronic batch report (EBT) - readable format

The EBT format of the Electronic Batch Report provides the same information as the pipe-delimitedformat, but in a readable format.

Electronic Batch Report (EBT) layout

Availity Customer ID: <<0>> Availity Electronic Batch Report----------------------------------------------------------------------------------------Date Received: <<1>> Time Received: <<2>>Availity Batch ID: <<3>> File Control Number: <<4>>Availity File ID: <<5>>File Name: <<6>>----------------------------------------------------------------------------------------Payer: <<7>> Payer ID: <<8>> Claim Responses Returned: <<9>> Charges: <<10>> Accepted Claims: <<11>> Charges: <<12>> Rejected Claims: <<13>> Charges: <<14>> ----------------------------------------------------------------------------------------Patient Name: <15>> From Date: <<16>> To Date: <<17>>Patient Control Number: <<18>> Charge: <<19>>Provider Billing ID: <<20>> Clearinghouse Trace #: <<21>>Payer Claim #: <<22>> Availity Trace #: <<23>>

Error Initiator: <<24>> Message Type: <<25>> Error Code: <<26>>Error Message: <<27>>Loop: <<28>> Segment ID: <<29>> Element #: <<30>>Version: <<31>>

Descriptions of fields in the EBT layout



1 Date Received CCYY-MM-DD

2 Time Received HH.MM.SS.SSS

3 Availity Batch ID File name assigned byAvaility or Batch of One:INTERNAL_FILENAME

4 File Control Number ISA13 on submitted file


Example: 1-123456789


7 Payer Name Availity payer name |UNKNOWN




8 Payer ID 2010BB NM109 (professional) |2010BC NM109 (institutional)

9 Claim Responses Returned Count of responses for thispayer breakdown

10 Charges Total of related charges for thispayer breakdown: 9,999.99format

11 Accepted Claims Count of accepted claims forthis payer breakdown

12 Charges Total of accepted charges forthis payer breakdown: 9,999.99format

13 Rejected Claims Count of rejected claims for thispayer breakdown

14 Charges Total of rejected charges forthis payer breakdown: 9,999.99format

15 Patient Name 2010BA/CA NM103, NM104


17 To Date 2400 DTP03 | 2300 DTP03;CCYYMMDD format

18 Patient Control Number 2300 CLM01

19 Charge 2300 CLM02; 9,999.99 format

20 Provider Billing ID 2010AA NM109


22 Payer Claim # If provided in payer response,else NA

23 Availity Trace # Outbound REF*D9




24 Error Initiator Availity | PSE | HIPAA – Weuse the 'Availity' value when wereject for unrecognized payer orsubmission of a test file in theproduction environment.

25 Message Type A | R | W | I

26 Error Code If provided, else NA

27 Loop Loop

28 Segment ID Segment ID

29 Element # Element number

30 Error Message Detailed claim error message

31 Version 5010

32 Bill Type Adjudicated claim informationreturned by some real timepayers.

33 Allowed Amount Adjudicated claim informationreturned by some real timepayers.

34 Non-Covered Amount Adjudicated claim informationreturned by some real timepayers.

35 Deductible Amount Adjudicated claim informationreturned by some real timepayers.

36 Co-Pay Amount Adjudicated claim informationreturned by some real timepayers.

37 Co-Insurance Amount Adjudicated claim informationreturned by some real timepayers.

38 Withhold Amount Adjudicated claim informationreturned by some real timepayers.




39 Estimated Payment Amount Adjudicated claim informationreturned by some real timepayers.

40 Patient Liability Amount Adjudicated claim informationreturned by some real timepayers.

Note:





Example: Electronic Batch Report (EBT)

Availity Customer ID: 0002176 Availity Electronic Batch Report---------------------------------------------------------------------------------Date Received: 2010-12-07 Time Received: 11.58.23.023Availity Batch ID: 2010120711582200 File Control Number: 000164875Availity File ID: 2010120711582200File Name: RespReport_test3.TXT---------------------------------------------------------------------------------Payer: HUMANA Payer ID: 61101Claim Responses Returned:2 Charges: 290.00Accepted Claims: 0 Charges: 0.00Rejected Claims: 2 Charges: 290.00---------------------------------------------------------------------------------Patient Name: SMITH, JADAFrom Date: 20101105 To Date: 20101105Patient Control Number:16386 Charge: 165.00Provider Billing ID: 9876543213 Clearinghouse Trace #: 467484130Payer Claim #: NA Availity Trace #: 27080

Error Initiator: HUMANA Message Type: RError Code: 42Error Message: Invalid use of NullVersion: 5010 Loop: NASegment ID: NA Element #: NA---------------------------------------------------------------------------------Patient Name: WOMAN, WONDERFrom Date: 20101107 To Date: 20101107Patient Control Number:16386 Charge: 125.00Provider Billing ID: 9876543213 Clearinghouse Trace #: 467484132Payer Claim #: NA Availity Trace #: 27081

Error Initiator: HUMANA Message Type: RError Code: 42Error Message: Invalid use of NullVersion: 5010 Loop: NASegment ID: NA Element #: NA------------------------------------------------------------------------------------------------------------------------------------------------------------------ END OF REPORT---------------------------------------------------------------------------------



277EBR Examples

Example: 277CA Positive Electronic Batch Report (EBR)

ISA*00* *00* *01*030240928 *ZZ*AV09311993 *110517*1345*^*00501*000356276*0*T*:~GS*HN*030240928*AV01101957*20110517*1345*356277*X*005010X214~ST*277*1001*005010X214~BHT*0085*08*356278*20110517*134514*TH~HL*1**20*1~NM1*PR*2*CORRECTCARE*****PI*CCIH~TRN*1*20110517134514367~DTP*050*D8*20110517~DTP*009*D8*20110517~HL*2*1*21*1~NM1*41*2*AVAILITY LLC*****46*030240928~TRN*2*239097104~STC*A1:20*20110517*WQ*259.5~QTY*90*1~AMT*YU*259.5~HL*3*2*19*1~NM1*85*2*PROVIDER*****XX*1234567890~TRN*1*0~QTY*QA*1~AMT*YU*259.5~HL*4*3*PT~NM1*QC*1*LASTNAME*FIRSTNAME****MI*K11111~TRN*2*TEST00013537401~STC*A1:20*20110517*WQ*259.5~REF*D9*239097104_16~DTP*472*RD8*20100831-20100831~SE*25*1001~GE*1*356277~IEA*1*000356276~

Example: 277CA Negative Electronic Batch Report (EBR)

ISA*00* *00* *01*030240928 *ZZ*AV09311993 *110526*1500*^*00501*000465756*0*T*:~GS*HN*030240928*AV01101957*20110526*1500*465757*X*005010X214~ST*277*1001*005010X214~BHT*0085*08*465758*20110526*150014*TH~HL*1**20*1~NM1*PR*2*ADVOCATE HEALTH PARTNERS*****PI*65093~TRN*1*20110526150014602~DTP*050*D8*20110526~DTP*009*D8*20110526~HL*2*1*21*1~NM1*41*2*AVAILITY LLC*****46*UB924010THIN~TRN*2*85371405~STC*A1:20*20110526*WQ*11591.49~QTY*AA*1~AMT*YY*11591.49~HL*3*2*19*1~NM1*85*2*PROVIDER*****XX*1234567890~TRN*1*0~REF*TJ*363695814~QTY*QC*1~AMT*YY*11591.49~HL*4*3*PT~NM1*QC*1*LASTNAME*FIRSTNAME****MI*123456-000~TRN*2*008990~STC*A3:448*20110526*U*11591.49********MISSING OR INVALID DATA PREVENTS CARRIER FROM PROCESSING THIS CLAIM~REF*D9*85371405~REF*BLT*214~DTP*472*RD8*20100801-20100824~SE*27*1001~GE*1*465757~IEA*1*000465756~



Delayed payer reportThe delayed payer report (also referred to as a DPR) includes information from payers that utilizebatch processing or other non-real-time adjudication processes. The report includes transaction receiptacknowledgement, transaction reject messaging, warning, and informational messages, as well asadjudication responses returned by the destination payer.

File extensions

• .DPR (delimited file)

• .DPT (human readable text file) – This is the default format.

• Summary report (errors and responses) – This is the default report.

• Detail report (all claims acknowledged)

• .277DPR – 277CA claim acknowledgement format.

Note: The .277DPR can only be received in combination with the .DPR or .DPT.


If late responses are received from the payer; typically within 30 days.

• Delayed payer reports are sent only for claims, not non-claim transactions.


Humana

Delayed payer reports are not generated for claims submitted to Humana.

Florida Blue

Delayed payer reports are not generated for claims submitted to Florida Blue.

Additional details

• If Availity does not receive delayed payer responses, we do not generate a report.

• If the payer processes claims on a batch schedule, rather than in real-time, or sends informationafter Availity has sent the EBR to your organization, Availity generates a delayed payer report.This may occur with small payers, non-direct payers, or payers who accept claims through anotherclearinghouse.

Next steps

Monitor status of transactions, correct and resubmit transactions with errors. If a delayed payer reportindicates the payer has rejected claims (line 2), you must correct and rebatch the rejected claims in yoursystem, and then upload and resubmit the file. Do not include accepted claims in the file.



Delayed payer report (DPR) - pipe delimited format

The pipe-delimited DPR file is intended to be imported into an automated system.

Delayed Payer Report (DPR) layout

DPR│Report Creation Date & Time│Availity Customer ID-Availity Batch ID│File Control Number│Customer ID| Availity File ID │Original File Name|CST|Availity Batch ID|Patient Account Number|Payer ID| Billing Provider ID|PatientLast Name, First Name| From Date|Total Charges|Process Date|Message Text|NA|Status|Payer Claim Number|SubmitterName|Billing Provider Name| Payer Name|Trace ID||

Note:

• Line 1 is the file/interchange level.

• Line 2 will occur for each patient loop in the file.

Example: Delayed Payer Report (DPR)

DPR|20101123133022000|0015515-2010112313302000|101019034|0015515|2010112313302000|PhysiciansHC_837P.txt|||CST|2010112313302000|CN1975-10|PHCS1|1234567893|LOCKLEAR, HEATHER|20100930|410.00|2010-11-23|A^^This claim has been accepted for further processing^^^|NA|ACK|CLM_001|AVAILITY LLC|DOCTOR, INDIVIDUAL|PHC TEXAS|240076456_0||

Delayed payer report (DPT) - readable format

The DPT format of the Delayed Payer Report provides the same information as the pipe-delimited format,but in a readable format.

Delayed Payer Report (DPT) layout

Availity Customer ID: <<0>> Availity Delayed Payer Report------------------------------------------------------------------------Date Received: <<1>> Time Received: <<2>>Availity Batch ID: <<3>> File Control Number: <<4>>Availity File ID: <<5>> File Name: <<6>>----------------------------------------------------------------------------5----10---15---20---25---30---35---40---45---50---55---60---65---70---75---8Patient Account Number: <<7>> Total Charges: <<8>>Patient Name: <<9>> Process Date: <<10>>From Date: <<11>> Status: <<12>>Billing Provider Name: <<13>> Billing Provider ID: <<14>>Billing Provider NPI: <<15>> Submitter Name: <<16>>Payer Name: <<17>> Payer Claim Number: <<18>>Payer ID: <<19>> Payer Seq Number: <<20>>Availity Batch ID: <<21>> Trace ID: <<22>>Claim Sequence #: <<23>> Message Type: <<24>> Message Code: <<25>>Message Loop: <<26>> Message Segment: <<27>>Message Element: <<28>> Message Text: <<29>>



Descriptions of fields in the DPT layout



1 Date Received Date response received: CCYY-MM-DD

2 Time Received Time response received:HH.MM.SS.SSS


4 File Control Number ISA13 on submitted file


Example: 1-123456789


7 Patient Account Number 2300 CLM01

8 Total Charges 2300 CLM02; 9,999.99 format

9 Patient Name 2010BA/CA NM103, NM104Max length = 25

If Patient Loop 2010CA ispresent and different from theSubscriber loop, the PatientNM103, NM104 is displayed.

The last name will be includedin its entirety then the remainingbytes will reflect the first name.

10 Process Date Date response was processedby Availity: CCYY-MM-DD


12 Status ACK | REJ

13 Billing Provider Name 2010BB, NM103

14 Billing Provider ID 2010BB, NM109




15 Billing Provider NPI NA (it is provided in theabove field or is absent fornontraditional providers)

16 Submitter Name 1000A, NM103

17 Payer Name Availity database payer nameassociated with payer ID

18 Payer Claim Number If provided in payer response,else NA

19 Payer ID 2010BB- NM109 - Professional

2010BC – NM109 - Institutional

20 Payer Seq Number NA – Availity does not createthis sequence



23 Claim Sequence # NA – Availity doesn't create aclaim sequence number

24 Message Type A | R | W | I

25 Message Code If provided, else NA

26 Message Loop Loop

27 Message Segment Segment ID

28 Message Element Element number

29 Message Text Claim error message

Note:







Example: Delayed Payer Report (DPT)

Availity Customer ID: 0015515 Availity Delayed Payer Report---------------------------------------------------------------------------------Date Received: 2010-11-23 Time Received: 13.30.22.022Availity Batch ID: 2010112313302000 File Control Number: 101019034Availity File ID: 2010112313302000File Name: PhysiciansHC_837P.txt---------------------------------------------------------------------------------Patient Account Number:CN1975-10 Total Charges: 410.00Patient Name: LOCKLEAR, HEATHER Process Date: 2010-11-23From Date: 20100930 Status: ACKBilling Provider Name: DOCTOR, INDIVIDUAL Billing Provider ID: 1234567893Billing Provider NPI: NA Submitter Name: Availity LLCPayer Name: PHC TEXAS Payer Claim Number: NAPayer ID: PHCS1 Payer Seq Number: NAAvaility Batch ID: 2010112313302000 Trace ID: 240076456_0Claim Sequence #: NAMessage Type: A Message Code: NAMessage Loop: NA Message Segment: NAMessage Element: NAMessage Text: This claim has been accepted for further processing--------------------------------------------------------------------------------- END OF REPORT---------------------------------------------------------------------------------



Health care services review (278ebr) summary text reportIn addition to the 278 ANSI ASC X12N response transactions, Availity also produces the Health CareServices Review (278ebr) summary text report.

278 summary text report layout, with errors, with HIPAA segment informationWhen errors are received as the response to the 278 request batch transaction, the layout of the report isas shown in the following table.

Health care services review (278ebr) summary text report

Date Received: Time Received:

Availity Batch ID: File Control Number:

Payer: 2010A – NM103(NM1_0200)

Type of Request: 2000F – UM01(UM_1690)

Patient Tracking Number:

Patient Name: Sub: 2010CA –NM103, NM104,NM105, NM107(NM1_0820)

Dep: 2010DA –NM103, NM104,NM105, NM107(NM1_1190)

Patient Date of Birth: Sub: 2010CA –DMG02 (DMG_0960)

Dep: 2010DA –DMG02 (DMG_1320)

Member ID: Sub: 2010CA – NM109(NM1_0820)

Dep: 2010DA – NM109(NM1_1190)

Patient Gender: Sub: 2010CA –DMG03 (DMG_0960)

Dep: 2010DA –DMG03 (DMG_1320)

Subscriber Name: 2010CA – NM103,NM104, NM105,NM107 (NM1_0820)

Supplemental ID: Sub: 2010CA – REF02(REF_0830)

Dep: 2010DA – REF02(REF_1200)

Error Message:

Error Code

Loop:

Message: 2000E – MSG01 (MSG_1510)



278 summary text report layout, no errors, with HIPAA segment informationWhen the 278 request transaction has passed all HIPAA validation, it is sent to the payer. The payerresponds with the 278 Health Care Services Review response transactions. The layout of the report is asshown in the following table.


Date Received: Time Received:

Availity Batch ID: File Control Number:

HCSR(s) Received: HCSR(s) Accepted:

Message

2000E – MSG01 (MSG_1510)

Payer: 2010A – NM103(NM1_0200)


Payer: 2010A – NM103(NM1_0200)


Patient TrackingNumber:

Patient Name: Sub: 2010CA –NM103, NM104,NM105, NM107(NM1_0820)

Dep: 2010DA –NM103, NM104,NM105, NM107(NM1_1190)

Patient Date of Birth: Sub: 2010CA –DMG02 (DMG_0960)

Dep: 2010DA –DMG02 (DMG_1320)

Member ID: Sub: 2010CA – NM109(NM1_0820)

Dep: 2010DA – NM109(NM1_1190)

Patient Gender: Sub: 2010CA –DMG03 (DMG_0960)

Dep: 2010DA –DMG03 (DMG_1320)

Subscriber Name: 2010CA – NM103,NM104, NM105,NM107 (NM1_0820)

Supplemental ID: Sub: 2010CA – REF02(REF_0830)

Dep: 2010DA – REF02(REF_1200)

Certification #: 2000F – HCR02(HCR_1700)

Status: 2000F – HCR01(HCR_1700)

Type of Service #1: 2000F – UM03 (UM_1690) – 1st loop

Type of Service #2: 2000F – UM03 (UM_1690) – 2nd loop




Type of Service #3: 2000F – UM03 (UM_1690) – 3rd loop

Type of Service #4: 2000F – UM03 (UM_1690) – 4th loop

Admission Date: 2000F – DTP03(DTP_1730 )

Service Date: 2000F – DTP03(DTP_1720 )

Effective Date: 2000F – DTP03(DTP_1780)

Expiration Date: 2000F – DTP03(DTP_1770)

Certification Date: 2000F – DTP03(DTP_1760)

Referred by Provider

Name: 2010B - NM103, NM104, NM105, NM107 (NM1_0480)

Tax ID: 2010B – NM109 (NM1_0480)

Payer Assigned ID: 2010B - REF02 (REF_0490)

Referred to Provider/Facility

(This loop can repeat up to 10 times.)

Name: 2010E - NM103, NM104, NM105, NM107 (NM1_1520)

Tax ID: 2010E – NM109 (NM1_1520)

Payer Assigned ID: 2010E - REF02 (REF_1530)

Lab & ClinicalInformation:

2000F – MSG01 (MSG_1910)



Proprietary payer reportFor UCare and Medicare DMERC regions B, C, and D, Availity passes a proprietary response directlyfrom the payer to the provider. These response files have a .RPT extension and are direct pass throughwithout any mapping or editing by Availity.


Availity® Health Information Network · intended to supplement, not replace, the standard HIPAA...

Documents

Transcript of Availity® Health Information Network · intended to supplement, not replace, the standard HIPAA...