AVAILITY.COM SPECIFICATION & DESIGN DOCUMENT › documents › support › B2B_SpecificationsGuide.pdfAvaility B2B transaction requests and responses must adhere to the syntax rules

© Availity, LLC, all rights reserved. | Confidential and proprietary.

Page 1 of 23 | Updated 1/30/2020

AVAILITY.COM SPECIFICATION & DESIGN DOCUMENT

Vendor Business-to-Business Specifications – Basic

1/30/2020 Version 3.10

Payer and Partner Connections



Table of Contents

Introduction .......................................................................................................................................................... 3

Purpose ........................................................................................................................................................... 3

Overview .......................................................................................................................................................... 3

Well-formed XML Syntax Rules ........................................................................................................................ 3

Message Specifications ....................................................................................................................................... 4

Message Envelope Request Specification ........................................................................................................ 4

Message Envelope Response Specification...................................................................................................... 5

The ASC X12N Specification ............................................................................................................................ 6

Recommended Test Cases ................................................................................................................................ 10

Appendix A: Error Conditions for Response XML Message ................................................................................ 11

Appendix B: Resources...................................................................................................................................... 15

Transaction Request URL .............................................................................................................................. 15

B2B Payer List ............................................................................................................................................... 15

Appendix C: Document Type Definitions and Data Examples ............................................................................. 16

Message Envelope DTD ................................................................................................................................. 16

AXIML Error Message DTD ............................................................................................................................ 16

Example Transaction Message ....................................................................................................................... 17

Sample C# XML Example ............................................................................................................................... 18

Appendix D: CAQH CORE Phase II Connectivity ............................................................................................... 20

Message Envelope Request Specification ...................................................................................................... 20

CORE Real-Time Request.............................................................................................................................. 21

WS-Security ................................................................................................................................................... 22

CORE Real-Time Response ........................................................................................................................... 22

Response Timeout and Retransmission Rules ................................................................................................ 22

Testing ........................................................................................................................................................... 23



Introduction

Purpose

The purpose of this document is to outline the process and message format envelope needed to contain the

health care transaction message received by Availity from third party vendors. This specification document is

designed to provide the fundamental aspects for implementing a B2B solution. It does not include any payer-

specific data elements or transaction requirements. Please refer to the individual payer’s B2B specification

documents for that level of detail, as they vary from payer to payer.

Important Note: As defined in the HIPAA Implementation Guides, companion documents like this Availity Vendor

Business-to-Business Specifications are intended to supplement, not replace, the standard HIPAA

Implementation Guide for each transaction set. Information in this guide is not intended to modify the definition,

data condition, or use of any data element or segment in the standard Implementation Guides. It is also not

intended to add any additional data elements or segments to the defined data set. This guide does not utilize any

code or data values that are not valid in the standard Implementation Guides. It also does not change the

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

Overview

During the testing process, you will be assigned an analyst to assist you in successfully implementing this product

with individual payers. You will be required to test each transaction that you plan to roll out. This will ensure a

successful and smooth implementation. Once production status has been granted, your ID must be activated in

the production environment, and then you can send your approved transactions. If you wish to add another

Availity payer or transaction to your service offering, we encourage you to contact us and complete the testing

process for the desired payer or transaction to ensure another smooth implementation, as some slight variations

among payers and transactions usually exist.

Well-formed XML Syntax Rules

Availity B2B transaction requests and responses must adhere to the syntax rules specified by the XML 1.0

specification. Well-formed XML does not allow certain characters to be used in their literal form. Availity does not

allow the “&”, “<”, and “>” characters in the literal (non-escaped) form in transaction requests or responses.

The following XML document escaped characters should be used in Availity B2B transaction requests instead of

non-escaped characters:

Escaped Characters Non-escaped Characters

< <

> >

& &

Availity B2B transaction responses will also use escaped characters instead of non-escaped characters.



Message Specifications

Message Envelope Request Specification

In an effort to support multiple message formats for each of the health care transactions (Eligibility & Benefits,

Claim Status Inquiry, etc), Availity has defined an “envelope” to contain the “body” of the message and any

“header” or supporting information required to process the request.

Field Description / Specifications XML Field Tags

Envelope Root XML element to house the header and body of the request message.

<ENVELOPE>

Header Holds the supporting elements for processing the request <ENVELOPE> <HEADER>

Transaction Type Transaction type

Valid values:

• 270 – E & B

• 276 – Claim Status Inquiry

• 278 – Auth/Referral

• 837 – Health Care Claim

Note: See Appendix C for information on B2B payers and the transactions they support.

<ENVELOPE> <HEADER> <TranCode>

Message Format Format of the Health Care related message in the envelope body.

Valid value: X12

<ENVELOPE> <HEADER> <MessageFormat>

Sender Field Length: 35

Recommended value: Sender’s organization name

<ENVELOPE> <HEADER> <Sender>

Receiver (Payer) Receiver of transaction

Valid value: AVAILITY

<ENVELOPE> <HEADER> <Receiver>

Session ID Unique session identifier provided by Availity during authentication process.

Optional – Used only for PKI authentication partners.

<ENVELOPE> <HEADER> <Session>

Provider Office Number Third party internal identifier for the site (provider office) that is requesting the transaction.

Assigned by the submitter; and must be alpha/numeric only.

<ENVELOPE> <HEADER> <ProviderOfficeNbr>

Provider Transaction ID Third party internal transaction identifier.

ID should be unique.

<ENVELOPE> <HEADER> <ProviderTransID>

Body Contains the body of the health care transaction message. Must be in the format of an X12 message as specified in the envelope header.

<ENVELOPE> <BODY>



Message Envelope Response Specification


Envelope Root XML element to house the header and body of the response message.

<ENVELOPE>

Header Holds the supporting elements for processing the transaction. <ENVELOPE> <HEADER>

Transaction Type Transaction type

Valid values:

• 271 - E & B Response

• 277 – Claim Status Response

• 278 – Auth/Referral Response

• VTXX – If Availity is unable to process the request.

<ENVELOPE> <HEADER> <TranCode>

Message Format Format of the Health Care related message in the envelope body.

Valid values:

• X12

• AXIML – Availity-formatted message for communicating non-health care-related responses.

<ENVELOPE> <HEADER> <MessageFormat>

Sender Field length: 35

Third-party vendor organization name.

Each organization must be registered with Availity and this field must match the name registered.

<ENVELOPE> <HEADER> <Sender>

Receiver (Payer) Receiver of transaction


<ENVELOPE> <HEADER> <Receiver>

SessionId Unique session identifier provided by Availity during authentication process.

Optional – Used only for PKI authentication partners.

<ENVELOPE> <HEADER> <Session>

Provider Office Number Third party internal identifier for the site (provider office) that is requesting the transaction.

<ENVELOPE> <HEADER> <ProviderOfficeNbr>

Provider Transaction ID Third party internal transaction identifier.

ID should be unique.

<ENVELOPE> <HEADER> <ProviderTransID>

Availity Transaction ID Availity transaction identifier returned to the submitter in the header XML. This is a unique identifier and consists of a maximum of 20 numeric characters

<ENVELOPE> <HEADER> <AvailityTranID>




Body Contains the body of the health care transaction response message. This must be in the format of an X12 message as specified in the envelope header MessageFormat tag.

If Availity is unable to process the message, an AXIML formatted error message will be returned. See appendix of this document for AXIML specification.

<ENVELOPE> <BODY>

The ASC X12N Specification

The purpose of this section is to outline the ASC X12N Control Segment specifications for real-time B2B

transmissions. These include the Interchange Control Header Segment (ISA), the Functional Group Header

Segment (GS), the Functional Group Trailer Segment (GE) and the Interchange Control Trailer Segment (IEA).

Note: Specific attention should be made to those segment element specifications to be followed in order for a

third party vendor to be identified and authenticated with Availity for each transaction request.

Interchange Control Header (ISA)

The ISA segment is the only EDI segment with a fixed length. A total of 105 positions are allowed in the ISA

segment, including the letters ISA; the asterisk (*) or other value used as an element delimiter; and the colon (:) or

other composite element delimiter. The value in position 106 is reserved for the tilde (~) or other segment

terminator character used to denote the end of each segment.

Once specified in the interchange header, the delimiters and terminators cannot be used in a data element value

elsewhere in the file. Availity can accept as a data element any value in the Basic and Extended Character Sets

referenced in Appendix B.1.1.2 5010 ANSI X12N Implementation Guides and accepted as X12 standard

compliant.

Data Element

Name Usage Availity Requirements

ISA01 Authorization Information Qualifier

Code to ID the type of information in the Authorization Information.

Field length: 2/2

03

ISA02 Authorization Information

Unique identification number assigned by Availity to the interchange sender.

Field length: 10/10

Value provided by Availity. Left justified, space filled.

ISA03 Security Information Qualifier

Code to identify the type of information in the Security Information field.

Field length: 2/2

01

ISA04 Security Information Unique password assigned by Availity to the interchange sender.

Field length: 10/10

Value provided by Availity. Left justified, space filled.



Data Element


ISA05 Interchange ID Qualifier

Qualifier to denote the system/method of code structure used to designate the sender.

Field length: 2/2

ZZ

ISA06 Interchange Sender ID

ID code for sender, as defined by Availity.

Field length: 15/15

AV09311993 Left justified, space filled.

ISA07 Interchange ID Qualifier

Qualifier to denote the system/method of code structure used to designate the receiver.

Field length: 2/2

01

ISA08 Interchange Receiver ID

ID code published by the receiver.

Field length: 15/15

030240928 Left justified, space filled.

ISA09 Interchange Date Date of the interchange.

Field length: 6/6

YYMMDD

ISA10 Interchange Time Time of the interchange.

Field length: 4/4

HHMM

ISA11 Repetition Separator This value is used to separate repeated occurrences of a simple data element or a composite data structure.

Field length: 1/1

This value must be different than the data element and component element separators, and the segment terminator.

ISA12 Interchange Control Version Number

This version number covers the interchange control segments.

Field length: 5/5

00501

ISA13 Interchange Control Number

A unique control number assigned by the sender.

Field length: 9/9

Tracking number assigned by the sender for the transaction. Must be a positive unsigned number and be identical to the value in IEA02.

Must be unique for a rolling twelve month period.

ISA14 Acknowledgement Requested

Code sent by the sender to request an interchange acknowledgement (TA1).

Field length: 1/1

0

Note: The TA1 is not supported for B2B. The real-time response will indicate any problems with the interchange.

ISA15 Usage indicator Code to indicate whether data enclosed is test or production.

Field length: 1/1

Use T until all Availity validation testing is complete. Then change to P in production.



Data Element


ISA16 Component Element Separator

The sender identifies the element separator used as a delimiter to separate the data within a composite data structure.

Field length: 1/1

This value must be different than the data element separator and the segment terminator.

Example ISA segment for real-time B2B transmission with authentication information. Spaces in the example

below are represented by ‘.’ for clarity.

ISA*03*SAMPLEID..*01*SAMPLEPWD.*ZZ*AV09311993.....*01*030240928......*090508*0003*^*00501*917753427*0*T*:~

Functional Group Header (GS)

Data Element


GS01 Functional Identifier Code

Code identifying the application related transaction set.

Field length: 2/2

Values:

• HS – Eligibility, Coverage or Benefit Inquiry (270)

• HB – Eligibility, Coverage or Benefit Information (271)

• HR – Health Care Claim Status Request (276)

• HN – Healthcare claim Status Notification (277)

• HI – Health Care Services Review Information (278)

• HC – Health Care Claim (837)

GS02 Application Sender’s Code

Code identifying the party sending the transmission.

Field length: 2/15

AV01101957

GS03 Application Receiver’s Code

Code identifying the party receiving the transmission.

Field length: 2/15

030240928

GS04 Date Date of functional group creation.

Field length: 8/8

CCYYMMDD

GS05 Time Time of functional group creation.

Field length: 4/8

HHMM.

GS06 Group Control Number

Assigned number originated and maintained by the sender.

Field length: 1/9

Tracking number assigned by the sender

for the transaction. Must be identical to the Trailer GE02.



Data Element


GS07 Responsible Agency Code

Code to ID the issuer of the standard.

Field length: 1/2

X – Accredited Standards Committee X12.

GS08 Version / Release /

Industry Identifier Code

Code indicating the version, release, sub

release and industry identifier of the EDI standard being used.

Field length: 1/12

Values

• 005010X279A1 – Eligibility, Coverage or Benefit Inquiry and Response (270/271)

• 005010X212 – Health Care Claim Status Request and Response (276/277)

• 005010X216 – Health Care Services Review Notification and Acknowledgement (278N)

• 005010X217 – Health Care Services Review Information (278)

• 005010X223A2 – Institutional Health Care Claim (837)

• 005010X222A1 – Professional Health Care Claim (837)

Functional Group Trailer (GE)

Data Element


GE01 Number of Transaction Sets Included

Total number of transaction sets included in the functional group or interchange (transmission) group.

Field length: 1/6

Positive unsigned numeric value.

GE02 Group Control Number

Assigned number originated and maintained by the sender.

Field length: 1/9

Tracking number assigned by the sender for the transaction. Must be identical to the Functional Group Header GS06 element.

Interchange Control Trailer (IEA)

Data Element


IEA01 Number of Included Functional Groups

A count of the number of functional groups included in an interchange.

Field length: 1/5

1


Page 10 of 23 | Updated 1/30/2020

Data Element


IEA02 Interchange Control Number

Unique control number assigned by the interchange sender.

Field length: 9/9

Tracking number assigned by the sender for the transaction. Must be identical to the Interchange Control Header ISA13 element.

Recommended Test Cases

The purpose of this section is to provide guidelines on how to test a new B2B Connection. Since Payers typically

have policies against creating test patients in production and QA databases, we cannot facilitate complete end-to-

end testing. We can instead provide you with guidelines which will allow for reasonable certainty that the

connection is established and working correctly.

Additionally, since B2B connections rely on the submitter’s Practice Management Software (PMS) user interface,

we cannot provide details on exactly what type responses will be displayed through the PMS user interface. We

can only give general expectations as to what type response will be presented from your specific PMS.


Page 11 of 23 | Updated 1/30/2020

Appendix A: Error Conditions for Response XML Message

The following business-to-business (B2B) error message enhancements are effective October 16, 2010. The

enhancements are designed to simplify transaction processing and more accurately identify processing errors.

The old ‘V’ error codes can be accompanied by new Cause and Assistance messages. The new Cause codes are

more specific and provide clarity around processing errors.

A sample error response and the entire list of Error Classes and Causes are listed below along with the old error

codes. Please contact your assigned account manager for more information.

Sample Error Response

<?xml version = "1.0" encoding="UTF-8"?><ENVELOPE><HEADER><TranCode>VT01</TranCode><MessageFormat>AXIML</MessageFormat> <Sender>EXTERNAL_TESTING</Sender><Receiver>AVAILITY</Receiver><Session>10019293</Session> <ProviderOfficeNbr>PV1002021</ProviderOfficeNbr><ProviderTransID>A002FF0032</ProviderTransID><AvailityTranId>9838402031</AvailityTranId> </HEADER><BODY><Interchange><Error><ErrorCode>VT01</ErrorCode><ErrorDescription>Generic description of the error code.</ErrorDescription> <CauseCode>001</CauseCode><CauseDescription>Optional message indicating what caused the error.</CauseDescription> <AssistanceMessage>Optional message informing the user how to contact Availity Client Services.</AssistanceMessage></Error></Interchange> </BODY></ENVELOPE>

Error Classes

Error Code

ErrorDescription Cause Message?

Assistance Message?

VT01 Availity is unable to process the request. Y Y

VT02 All connections are occupied with other requests. Please try this request again later. N N

VT03 We are currently unable to complete your request. The allowable submission limit has been reached for this submitter/payer/transaction type.

N N

VT04 Availity is unable to understand your transaction request. Y Y

VT05 Availity is experiencing problems communicating with the payer. Y Y

VT06 Availity is unable to understand the payer's response. Y Y

VT07 Availity is encountering hardware or software failures. Y Y

Error Causes

Cause Code

Cause Description Assistance Message

New Error Class(es)

Old Error Code

001 The ISA segment in the request has missing elements (i.e. ISA12 is missing) or the ISA segment is missing altogether. Please verify and correct the ISA segment and resubmit the request.

1

VT01

-------

VT04 (Redundant)

VT06 (Redundant)

VT09


Page 12 of 23 | Updated 1/30/2020

Cause Code


New Error Class(es)

Old Error Code

002 The GS segment in the request has missing elements (i.e. GS08 is missing) or the GS segment is missing altogether. Please verify and correct the GS segment and resubmit the request.

1

VT01

-------

VT04 (Redundant)

VT06 (Redundant)

VT01

003

The BHT segment in the request has missing elements (i.e. BHT06 is missing) or the BHT segment is missing altogether. Please verify and correct the BHT segment and resubmit the request.

1

VT04

VT01 (837p)

-------

VT06 (Redundant)

VT09

004 The GE segment in the request has missing elements (i.e. GE01 is missing) or the GE segment is missing altogether. Please verify and correct the GE segment and resubmit the request.

1

VT04

-------

VT06 (Redundant)

VT09

005 The IEA segment in the request has missing elements (i.e. IEA01 is missing) or the IEA segment is missing altogether. Please verify and correct the IEA segment and resubmit the request.

1

VT04

-------

VT06 (Redundant)

VT09

006

An NM1 segment in the request has missing elements (i.e. NM109 is missing) or the NM1 segment is missing altogether. Please verify and correct the NM1 segment and resubmit the request.

1 VT04 VT09

007 The ISA segment in the response has missing elements (i.e.

ISA12 is missing) or the ISA segment is missing altogether. Please try this request again later.

1 VT06 VT12

008 The GS segment in the response has missing elements (i.e. GS08 is missing) or the GS segment is missing altogether. Please try this request again later.

1 VT06 VT12

009 The BHT segment in the response has missing elements (i.e. BHT06 is missing) or the BHT segment is missing altogether. Please try this request again later.

1 VT06 VT12

010 The GE segment in the response has missing elements (i.e. GE01 is missing) or the GE segment is missing altogether. Please try this request again later.

1 VT06 VT12

011 The IEA segment in the response has missing elements (i.e. IEA01 is missing) or the IEA segment is missing altogether. Please try this request again later.

1 VT06 VT12

012 The request does not contain a transaction. Please correct and resubmit it.

1

VT01

-------

VT04 (Redundant)

VT02


Page 13 of 23 | Updated 1/30/2020

Cause Code


New Error Class(es)

Old Error Code

013 The response does not contain a transaction. Please try this request again later.

1 VT06 VT12

014 Availity could not parse the XML envelope because it was invalid. Please correct the request and resubmit it.

1 VT01 VT03

015 Required message values in the request are missing or invalid. One or more fields in the XML envelope were missing: ${1} Please correct the request and resubmit it.

1 VT01 VT09

016 The session ID ${1} contains invalid characters. All characters must be numeric. Please verify and correct the session ID and resubmit the request.

1 VT01 VT07

017 Availity determined that the account name for user ID in ISA02 (${1}) is inactive.

2 VT01 VT13

018 Availity does not recognize the user ID in ISA02 (${1}. Please verify and correct the user ID and resubmit the request.

1 VT01 VT13

019 According to Availity's system, the password in ISA04 does not

match the user ID in ISA02 (${1}). Please verify and correct the user ID or password and resubmit the request.

1 VT01 VT13

020 Either the session ID, the user ID, or both are absent from the request. Please correct the request and resubmit it.

1 VT01 VT06

021 Availity cannot find the session ID (${1}) in its database or has determined the session ID is invalid. Please verify and correct the session ID and resubmit the request.

1 VT01 VT07

022 The session ID (${1}) has expired. Please obtain a new session ID and resubmit the request.

1 VT01 VT08

023 The vendor is not configured with Availity. 2 VT01 VT15

024 Availity is unable to determine the transaction type or the transaction type is invalid. Please verify and correct the transaction type in the XML envelope and resubmit the request.

1 VT01 VT01

025 Availity does not recognize this receiver (${1}) and transaction type combination. Please verify the receiver name and transaction type fields and resubmit the request.

1 VT01 VT01

026 The HIPAA version in the ISA12 segment is either missing or invalid. Please verify and correct the ISA12 segment and resubmit the request.

1 VT01

New -

Would map to VT09

027 The BODY element must contain an X12 transaction. In other words, the request contains an XML envelope but does not contain an X12 transaction. Please correct and resubmit it.

1 VT01 VT01

028 The message format in the request must be X12. Please correct and resubmit the request.

1 VT01 VT09


Page 14 of 23 | Updated 1/30/2020

Cause Code


New Error Class(es)

Old Error Code

029 Vendor pool full for vendor ID ${1}. 1 VT02 VT14

030 Mediator pool full for receiver. 1 VT02 VT11

031 One or more transaction caps met. 1 VT03 VT17

032 A HIPAA validation error has occurred when validating the request: ${1}.

1 VT04 VT09

033 A HIPAA validation error has occurred when validating the payer's response: ${1}. Please try this request again later.

1 VT06 VT12

034

The subscriber identifier (ID) must contain 4 to 17 characters and

no spaces. For Blue Cross and Blue Shield, it should contain either a three-letter alphabetic prefix or a prefix containing R and two numeric digits, followed by up to 14 alphanumeric characters. Please correct and resubmit.

1 VT04 VT16

035 Availity and the payer are unable to communicate because the connection has failed or a timeout occurred. Please try this request again later.

1 VT05 VT10

036 The format of the payer's response is invalid. Please try this request again later.

1 VT06 VT12

037 Please try this request again later. 1 VT07 VT01

038 The transaction contains multiple ST/SE segments, but only one ST/SE is allowed. Please correct the transaction and resubmit it.

1 VT01 VT09

039

The 4010A1 278 contains a combination of a specialty care review, health services review, and an admission review (multiple 'events'), denoted by multiple 2000F loops. Converting this 278 to 5010 results in multiple ST/SE segments, which are not allowed. Please separate the events into separate 278s and resubmit them.

1 VT04 VT09

040 The format of the payer's response is invalid. Please try this request again later.

2 VT06 VT12

Assistance Message 1

If this problem persists, please contact Availity Client Services at 1-800-AVAILITY between 8:00 am and 7:00 pm

ET Monday through Friday.

Assistance Message 2

Please contact Availity Client Services at 1-800-AVAILITY between 8:00 am and 7:00 pm ET Monday through

Friday.


Page 15 of 23 | Updated 1/30/2020

Appendix B: Resources

Transaction Request URL

Use the following URL for submitting the transaction request to Availity’s test environment:

https://qa-apps.availity.com/availity/B2BHCTransactionServlet

Use the following URL for submitting the transaction request to Availity’s production environment:

https://apps.availity.com/availity/B2BHCTransactionServlet

The request will currently read the xml message from the request input stream or accept a parameter of

‘transaction’ to obtain the xml message.

B2B Payer List

Use this link for a list of B2B payers and the transactions they support.

http://www.availity.com/resources/in-our-network/payer-lists/

https://qa-apps.availity.com/availity/B2BHCTransactionServlet

https://apps.availity.com/availity/B2BHCTransactionServlet

http://www.availity.com/resources/in-our-network/payer-lists/


Page 16 of 23 | Updated 1/30/2020

Appendix C: Document Type Definitions and Data Examples

Message Envelope DTD

The following is an example of a message envelope Document Type Definition (DTD).

<!ELEMENT ENVELOPE ( HEADER, BODY ) >

<!ELEMENT HEADER (TranCode, MessageFormat, Sender, Receiver, Session?, ProviderOfficeNbr, ProviderTransID) >

<!ELEMENT TranCode (#PCDATA) >

<!ELEMENT MessageFormat (#PCDATA) >

<!ELEMENT Sender (#PCDATA) >

<!ELEMENT Receiver (#PCDATA) >

<!ELEMENT Session (#PCDATA) >

<!ELEMENT ProviderOfficeNbr (#PCDATA) >

<!ELEMENT ProviderTransID (#PCDATA) >

<!ELEMENT BODY (#PCDATA) >

AXIML Error Message DTD

The following is an example of an AXIML error message Document Type Definition (DTD).

<!ELEMENT Interchange ( Error ) >



<!ELEMENT Error (ErrorCode, ErrorDesc) >

<!ELEMENT ErrorCode (#PCDATA) > 

<!ELEMENT ErrorDesc (#PCDATA) > 


Page 17 of 23 | Updated 1/30/2020

Example Transaction Message

The following is an example of a 276 X12 message wrapped within the Availity message envelope. Please note

that carriage return, line feeds (CR/LFs) have been added at the end of each line/segment to make it easier to

read.

<?xml version = "1.0" encoding="UTF-8"?>

<ENVELOPE>

<HEADER>

<TranCode>276</TranCode>

<MessageFormat>X12</MessageFormat>

<Sender>SAMPLE ORGANIZATION</Sender>

<Receiver>AVAILITY</Receiver>

<Session></Session>

<ProviderOfficeNbr>00000000670</ProviderOfficeNbr>

<ProviderTransID>917753427</ProviderTransID>

</HEADER>

<BODY>

ISA*03*SAMPLEID *01*SAMPLEPWD *ZZ*AV09311993 *01*030240928 *110301*2144*^*00501*000648085*0*P*:~

GS*HR*AV01101957*030240928*20110301*214457*1*X*005010X212~

ST*276*0001*005010X212~

BHT*0010*13*1000648085*20110301*2144~

HL*1**20*1~

NM1*PR*2*PAYER NAME*****PI*PAYERID~

HL*2*1*21*1~

NM1*41*2*SAMPLE SUBMITTER*****46*123456789~

HL*3*2*19*1~

NM1*1P*2*SAMPLE PROVIDER*****XX*1234567893~

HL*4*3*22*0~

DMG*D8*19241010*M~

NM1*IL*1*PATIENT*SAMPLE****MI*987654321~

TRN*1*000648085~

REF*EJ*UNKNOWN~

AMT*T3*0~

DTP*472*RD8*20101203-20101207~

SE*16*0001~

GE*1*1~

IEA*1*000648085~

</BODY>

</ENVELOPE>


Page 18 of 23 | Updated 1/30/2020

Sample C# XML Example

using System;

using System.IO;

using System.Net;

using System.Text;

using System.Xml;

using RealMed.Exception;

namespace RealMed.Payer.Connection

{

public class B2BXmlClient

{

public string Url { get; set; }

public string UserName { get; set; }

/// <summary>

/// Send 270/276 transaction to Aries realtime web service

/// </summary>

/// <param name="payloadId">unique identifier</param>

/// <param name="payload">ANSI 270 or 276 request</param>

/// <param name="transactionCode">transaction code (either '270' or '276')</param>

/// <param name="receiverCode">AVAILITY</param>

/// <returns>ANSI 271 or 277 response</returns>

public string Send(string payloadId, string payload, string transactionCode, string receiverCode)

{

string ansiResponse = "";

try

{

var xd = new XmlDocument();

xd.LoadXml("<?xml version=\"1.0\"?><ENVELOPE/>");

var xnHeader = xd.DocumentElement.AppendChild(xd.CreateElement("HEADER"));

xnHeader.AppendChild(xd.CreateElement("TranCode")).InnerText = transactionCode;

xnHeader.AppendChild(xd.CreateElement("MessageFormat")).InnerText = "X12";

xnHeader.AppendChild(xd.CreateElement("Sender")).InnerText = UserName;

xnHeader.AppendChild(xd.CreateElement("Receiver")).InnerText = receiverCode;

xnHeader.AppendChild(xd.CreateElement("Session"));

xnHeader.AppendChild(xd.CreateElement("ProviderOfficeNbr")).InnerText = "office_number_here";

xnHeader.AppendChild(xd.CreateElement("ProviderTransID")).InnerText = payloadId;

xd.DocumentElement.AppendChild(xd.CreateElement("BODY")).InnerText = payload;

var httpRequest = (HttpWebRequest) WebRequest.Create(Url);

httpRequest.Method = "POST";

httpRequest.ContentType = "application/x-www-form-urlencoded";

var xmlRequest = xd.OuterXml.Replace("<Session />", "<Session></Session>");

SendRequest(httpRequest, xmlRequest);

var xmlResponse = GetResponse(httpRequest);


Page 19 of 23 | Updated 1/30/2020

if (!string.IsNullOrEmpty(xmlResponse))

{

xd.LoadXml(xmlResponse);

var xnTemp = xd.DocumentElement.SelectSingleNode("BODY");

if (xnTemp != null)

{

var xnError = xnTemp.SelectSingleNode("Interchange/Error");

if (xnError != null)

{

ansiResponse = xnError.InnerText;

}

else

{

ansiResponse = xnTemp.InnerText;

}

}

}

return ansiResponse;

}

catch (System.Exception ex)

{

throw new RMException(ex);

}

}

protected virtual void SendRequest(HttpWebRequest request, string payload)

{

using (var writer = new StreamWriter(request.GetRequestStream(), Encoding.Default))

{

writer.Write(payload);

}

}

protected virtual string GetResponse(HttpWebRequest request)

{

var response = (HttpWebResponse) request.GetResponse();

using (var reader = new StreamReader(response.GetResponseStream()))

{

return reader.ReadToEnd();

}

}

}

}


Page 20 of 23 | Updated 1/30/2020

Appendix D: CAQH CORE Phase II Connectivity

In support of the CAQH CORE Phase II mandate, Availity offers a fully compliant connectivity solution (See

Testing section for URLs.)

Availity can receive real-time requests using either Envelope Standard A (HTTP MIME Multipart) or Envelope

Standard 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 for Envelope Standard B. For more

information, see Phase I CORE 153: Eligibility and Benefits Connectivity Rule and Phase II CORE 270:

Connectivity Rule.

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

Service name Description

realTimeTransaction Submit a real time transaction, synchronous call.

The response follows the CORE response example given in the CAQH CORE Phase II Operating Rules. For

more information on CAQH CORE Phase II Operating Rules, see CAQH CORE Phase II Operating Rules.

Message Envelope Request Specification

In an effort to support the CAQH Core standard, Availity has implemented a SOAP-based web service that

defines a standard envelope for all B2B transactions. The XML wrapper for all B2B transactions is comprised of

two parts: a SOAP Envelope, which must include Header and Body elements; and a CORE Real-Time Request

message contained within the SOAP Body.

The example below shows the SOAP Header with required security meta-data and the SOAP Body with the

required elements of CORE Real-Time Request message.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">

<soapenv:Header>

<wsse:Security>...</wsse:Security>

</soapenv:Header>

<soapenv:Body>

<ns1:COREEnvelopeRealTimeRequest

xmlns:ns1="http://www.caqh.org/SOAP/WSDL/CORERule2.0.1.xsd">

<PayloadType>X12_270_Request_005010X279A1</PayloadType>

<ProcessingMode>RealTime</ProcessingMode>

<PayloadID>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</PayloadID>

<TimeStamp>2007-08-30T10:20:34Z</TimeStamp>

<SenderID>SAMPLEID</SenderID>

<ReceiverID>AVAILITY</ReceiverID>

<CORERuleVersion>2.0.1</CORERuleVersion>

<Payload>

<![CDATA[ISA*00* *00* *ZZ*...IEA*1*000000031]]>

</Payload>

</ns1:COREEnvelopeRealTimeRequest>

</soapenv:Body>

</soapenv:Envelope>

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



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


Page 21 of 23 | Updated 1/30/2020

CORE Real-Time Request

The following table describes the elements of the CORE Real-Time Request:

Field Description XML Tag

Envelope Real-time request envelope <COREEnvelopeRealTimeRequest>

Payload Type Specifies the type of payload included within the request. 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

<PayloadType>

Processing Mode Indicates processing mode. Must be: RealTime. <ProcessingMode>

Payload ID A Payload identifier assigned by the Sender. (not required) <PayloadID>

Time Stamp Sender provided time stamp indicating when a message is

created and sent. Must be in Coordinated Universal Time (UTC) format, e.g., 2007-08-30T10:20:34Z

(not required)

<TimeStamp>

Sender ID Unique user name provided by Availity at the completion of the Advanced Clearinghouse registration process. This ID must match the username in the WS-Security header.

<SenderID>

Receiver ID Identifier of the receiver (not required).


<ReceiverID>

CORE Rule Version The CORE Rule version that this envelope is using. (not required)

<CORERuleVersion>

Payload The X12 transaction enclosed within an XML CDATA element.

<PayLoad>


Page 22 of 23 | Updated 1/30/2020

WS-Security

You must insert the WS-security username and password token (see example below) into the SOAP header for

the message to be accepted. Availity provides the username and password credentials at the completion of

registration.


<soapenv:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand=”true”>

<wsse:UsernameToken xmlns:wsu=” http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id=”UsernameToken=21621664”>

<wsse:Username>SAMPLEID</wsse:Username>

<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token- profile-1.0#PasswordText">SAMPLEPWD</wsse:Password>

</wsse:UsernameToken>

</wsse:Security>

</soapenv:Header>

<soapenv:Body>...</soapenv:Body>

</soapenv:Envelope>

Note: Replace SAMPLEID and SAMPLEPWD with the user ID and password provided by Availity.

CORE Real-Time Response

The example below shows the standard envelope nodes for the CORE Real-Time Response message.


<soapenv:Body>

<ns1:COREEnvelopeRealTimeResponse xmlns:ns1="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">

<PayloadType>X12_271_005010X279A1</PayloadType>

<ProcessingMode>RealTime</ProcessingMode>

<PayloadID>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</PayloadID>

<TimeStamp>2007-08-30T10:20:34Z</TimeStamp>

<SenderID>sampleID</SenderID>

<ReceiverID>AVAILITY</ReceiverID>

<CORERuleVersion>2.0.1</CORERuleVersion>

<Payload><![CDATA[ISA*00* *00* *ZZ*NEHEN780 *ZZ*NEHEN003 ...IEA*1*000000031]]></Payload>

<ErrorCode>Success</ErrorCode>

<ErrorMessage></ErrorMessage>

</ns1:COREEnvelopeRealTimeResponse>

</soapenv:Body>

</soapenv:Envelope>

Response Timeout and Retransmission Rules

For each real-time request submitted, a response must be returned within 60 seconds. If no response is returned,

Availity will process duplicate transactions based on the following rules:

• The submitter’s system may send a duplicate transaction after 90 seconds.

• If no response is received after the second attempt, the submitter’s system may re-submit the transaction

no more than 5 times within the next 15 minutes.


Page 23 of 23 | Updated 1/30/2020

Testing

A Connectivity Solutions representative will guide you through the testing process. Use the following URLs for

submitting CAQH CORE formatted transactions:

The URL for submitting to QA:

https://qa-gateway.availity.com:4021/core

The URL for submitting to Production:

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

https://qa-gateway.availity.com:4021/core

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

Documents

AVAILITY.COM SPECIFICATION & DESIGN DOCUMENT › documents › support › B2B_SpecificationsGuide.pdfAvaility B2B transaction requests and responses must adhere to the syntax rules