Indiana Health Coverage Programs. Communications Guide

(1)

Indiana Health

Coverage Programs

Communications Guide

Companion Guide Version Number: 2.1

Library Reference Number: CLEL10010

Revision Date: December 2013

(2)

(3)

Contents ... iii

Introduction ... 4

Connectivity Options ... 4

CORE Web Services ... 5

NOTE: The SOAP security header must not contain the attribute: mustUnderstand=”true” ... 5

Functionality at a glance ... 5

Connecting to the Server ... 5

CORE Service Types ... 6

File Exchange ... 7

FTP over SSL ... 7

FTP over SSH ... 9

Web interChange - HTTP over SSL ... 12

HP Delivery and Support System (DASS) - Interactive Submission ... 13

DASS errors from the Device Handler ... 15

DASS errors from the Bridge ... 15

DASS errors from the Host process ... 16

(4)

December 2013 4

Introduction

This document is intended for software vendors who wish to develop applications to exchange electronic transactions with the Indiana Health Coverage Programs (IHCP) file delivery and retrieval systems that are maintained by HP Enterprise Services (HPES) for the purpose of uploading and downloading HIPAA-compliant transactions.

The information included identifies the options available for submitting and receiving transaction exchanging 270/271 and 276/277 batch and interactive transactions and returning 835

remittance advice transactions data and provides specific details for each option.

Connectivity Options

IHCP connectivity interfaces support three of the most commonly used channels of

communication, giving clients a variety of interfaces to develop robust interchange solutions. Batch and interactive submission options are available.

FTPS and SFTP using:

 CORE compliant web services – used for batch and interactive 270/271 and 276/277 transactions and 835 remittance advice transactions

 File Exchange – used for batch transactions

 HP Delivery and Support System (DASS) -– used for interactive 270/271 and 276/277 transactions

HTTP/S (Web interChange) - used to interact with File Exchange in a manual, or ad-hoc manner.

The table below identifies submission options available for all transactions.

Transaction CORE Services

Batch and Interactive File Exchange Batch DASS Direct Connection Interactive

837I Health Care Claim Institutional x

837P Health Care Claim Professional x

837D Health Care Claim Dental x

835 Remittance Advice (RA) x x

270/271 Eligibility Benefit Inquiry and Response

x x x

276/277 Claim Status Request and Response

x x x

278 Prior Authorization (PA) Request for Review and Response

x

834 Managed Care Member Enrollment Roster

x

820 Managed Care Capitation Payment Reporting

(5)

CORE Web Services

IHCP’s CORE compliant web services are built around ACA 1104 Phase I,II and III rules which can be found at http://caqh.org/CORE_operat_rules.php

CORE-compliant Envelope Specifications using Message Enveloping Standards can be found in the Phase II CORE 270: Connectivity Rule document.

http://caqh.org/pdf/CLEAN5010/270-v5010.pdf

IHCP’s CORE compliant web services are capable of exchanging 270/271 and 276/277 batch and interactive transactions and returning 835 remittance advice transactions using either of the two HTTP/S envelope standards: MIME-Multipart form data and SOAP+WSDL. Each envelope must conform to the CORE requirements as listed in the CORE Phase I and Phase II rules referenced above for envelope version 2.2.0.

NOTE: The SOAP security header must not contain the attribute: mustUnderstand=”true”

Functionality at a glance

HTTP/S supports a request-response message pattern, meaning that the sender must submit a message and wait for a response from the recipient. This usage pattern applies to batch and interactive ASC X12 transactions. The response message varies based on whether the sender’s message was an interactive request, batch submission, or batch response retrieval request.

Connecting to the Server

Users can connect to the web service using a network connection that provides access to the public internet. The envelope standard used will determine the application endpoint URL that will be used to connect to and interact with IHCP’s CORE services.

Service requests using SOAP 1.2 should use

https://soiesb.in.gov/FSSA/IHCP_SOAP/CoreTransactions.svc

Service requests using the MIME-multipart form data HTTP envelope should use

https://soiesb.in.gov/FSSA/IHCP_MIME/CoreTransactions.aspx

(6)

Indiana Health Coverage Programs

December 2013 6

CORE Service Types

Processing Modes

 Batch  Interactive

Interactive Payload Types

Request PayloadTypes (sent by trading partner)  X12_270_Request_005010X279A1  X12_276_Request_005010X212

Response PayloadTypes (returned by IHCP)  X12_271_Response_005010X279A1  X12_277_Response_005010X212

Batch Payload Types

Batch Upload Request PayloadTypes (sent by trading partner)  X12_270_Request_005010X279A1

 X12_276_Request_005010X212

 X12_999_SubmissionRequest_005010X231A1

o This payload type only logs that the submitter is acknowledging receipt of a requested download

Batch Upload ResponseType (returned by IHCP)  X12_Response_ConfirmReceiptReceived

o For the submission of an X12_999_SubmissionRequest_005010X231A1 X12_BatchReceiptConfirmation

o For the submission of an X12_270_Request_005010X279A1 and X12_276_Request_005010X212

Batch Download Request PayloadTypes (sent by trading partner)  X12_005010_Request_Batch_Results_271

 X12_005010_Request_Batch_Results_277  X12_005010_Request_Batch_Results_835  X12_999_RetrievalRequest_005010X231A1

Batch Download Response PayloadTypes (returned by IHCP)  X12_271_Response_005010X279A1

 X12_277_Response_005010X212  X12_835_Response_005010X221A1  X12_999_Response_005010X231A1 X12_005010_Response_NoBatchResultsFile

(7)

File Exchange

File Exchange is an application provided by the IHCP for secure file processing, storage, and transfer of batch transaction files. File Exchange is designed to safely and securely collect, store, manage, and distribute sensitive information between IHCP and its trading partners. Web browsers and no- or low-cost secure FTP clients, who are required to transfer files, can quickly, easily, and securely exchange files with File Exchange over encrypted connections using the FTP over SSL (FTPS), FTP over SSH (SFTP), and HTTP over SSL (HTTPS) protocols. Typically, trading partners that wish to interact systematically with File Exchange (via a batch script) will choose one of the two FTP methods listed above.

For data file submission, in addition to accepting normal text files, File Exchange can also accept compressed files submitted in ZIP format. The file name that is submitted must have .zip at the end of the file name. The zip file can contain a single file or multiple files. When these files are processed, File Exchange will extract all files from the ZIP archive and process them as though they were submitted individually. There are no restrictions related to submitted file names other than those for ZIP files discussed above. Any meaningful file name can be chosen by the trading partner. All HIPAA transaction files must be uploaded to the /Distribution/HIPAA Transactions folder.

All outbound files available for download are created individually with the following naming convention: SSSS.TTT.X.HHMMSS.JJJ(where SSSS = trading partner ID, TTT = transaction type, X = transmission type – always an X, HHMMSS = hours/minutes/seconds, and JJJ = Julian date). All outbound report files available for download are also created individually with the following naming convention: SSSS.TTT.rpt.X.HHMMSS.JJJ (where SSSS = trading partner ID, TTT = transaction type, X = transmission type – always an X, HHMMSS =

hours/minutes/seconds, and JJJ = Julian date). Outbound files are not available in a

compressed or ZIP format. All outbound files will be placed in the trading partner’s home folder. These files will remain available for retrieval for 30 days after they first become available unless they are explicitly deleted from File Exchange by the trading partner.

FTP over SSL

The first File Exchange batch transmission option is FTP over SSL. The following

documentation is designed to assist developers with customizing secure FTP clients using FTP over SSL to enable connectivity to File Exchange. File Exchange fully supports a large number of secure FTP clients using FTP over SSL including the following:

AS/400 native FTPS client

C-Kermit (command-line, v8.0+, VMS, Linux, Unix, Solaris, and so forth.) Cute FTP Pro (GUI, version 1.0 and higher)

Glub FTP (GUI, Java 2.0 and higher) IP*Works SSL (API, Windows, version 5.0)

LFTP (command-line, Linux, Unix, Solaris, and so forth.) MOVEit Buddy (GUI)

(8)

December 2013 8

MOVEit Freely (command line) NetFinder (GUI, Apple)

NetKit (command-line, Linux, Unix, Solaris, and so forth.) OpenIT (Unisys V-Series, A-Series, Clearpath)

SmartFTP (GUI, version 1.0 and higher)

SurgeFTP (command-line, Solaris, and so forth) WS_FTP Pro (GUI, version 7.0 and higher)

The important pieces of information that are needed no matter which FTP over SSL client is used are listed below. Consult the documentation for your specific FTP client to determine how to configure these settings. If the machine that is initiating the FTP connection resides behind a firewall, the firewall must be configured to allow outbound traffic on any of the ports listed below.

 Host – xfile.indianamedicaid.com  Control Connection Ports

 990 if using implicit encryption (recommended)  21 if using explicit encryption

 Data Connection Ports – 3000-3100 (any port in this range)

 Transfer mode – Passive (Active mode transfers will not be accepted)

The following examples were tested using the MOVEit Freely® command-line client in a Windows environment. Note that in these examples, the mput, mget and mdelete commands were used with a file mask to process multiple files at a single time. Not all secure FTP clients support these commands. It is recommended that the FTP client used to communicate with File Exchange support these commands. If an FTP client that does not support these multiple file commands is used to communicate with File Exchange, then the sample scripts will need to be modified to create multiple put, get, and delete statements that are input into the FTP client. Check the documentation for the specific FTP client being used for more information on commands supported by the FTP client. Figures 2.1 and 2.2 are examples of data file submission and retrieval using FTPS.

(9)

Figure 2.1 – Data File Submission Using File Exchange

Figure 2.2 – Data File Retrieval Using FTPS @echo off

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * rem * Example DOS batch script that will get all files

rem * containing a certain file mask from a user's rem * File Exchange home directory and save them to rem * the current local directory.

rem * (via secure FTP over SSL using MOVEit Freely) rem *

rem * Usage:

rem * "getfiles (username) (password) (filemask)" rem * ex. putfiles john123 mypass *.*

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * echo cd /Home/%1 > temp.txt

echo prompt >> temp.txt echo mget %3 >> temp.txt

rem ** Optional: Uncomment line below to delete the files from File Exchange rem ** after they are retrieved

rem echo mdelete "%3" >> temp.txt echo quit >> temp.txt

ftps -e:implicit -a -user:%1 -password:%2 -s:temp.txt xfile.indianamedicaid.com del temp.txt

FTP over SSH

Another File Exchange batch transmission option is FTP over SSH. The following

documentation is designed to assist developers with customizing secure FTP clients using FTP

@echo off

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * rem * Example DOS batch script that will copy all files

rem * containing a certain file mask from rem * a local directory to File Exchange.

rem * (via secure FTP over SSL using MOVEit Freely) rem *

rem * Usage:

rem * "putfiles (username) (password) (filemask)" rem * ex. putfiles john123 mypass *.*

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * echo cd "/Distribution/HIPAA Transactions" > temp.txt

echo prompt >> temp.txt

echo mput "C:\temp\upload\%3" >> temp.txt echo quit >> temp.txt

ftps -e:implicit -a -user:%1 -password:%2 -s:temp.txt xfile.indianamedicaid.com del temp.txt

(10)

December 2013 10

over SSH to enable connectivity to File Exchange. File Exchange fully supports the most popular secure FTP clients using FTP over SSH including the following:

F-Secure SSH (command-line, 3.2.0 Client for Unix) OpenSSH SFTP (command-line, Unix)

OpenSSH for Windows (command-line, Windows) PSFTP/PSCP (command-line, Windows)

SSH Communications SSH Secure Shell FTP (GUI, Windows) WS_FTP (GUI, Windows)

The important pieces of information that are needed no matter which FTP over SSH client is used are listed below. Consult the documentation for your specific FTP client to determine how to configure these settings. If the machine that is initiating the FTP connection resides behind a firewall, the firewall must be configured to allow outbound traffic on the port listed below.

 Host – xfile.indianamedicaid.com  Port – 22 (this is the default SSH port)

The following examples were tested using the PSFTP/PSCP command-line client. Note that the standard commands included with FTP over SSH clients do not include the multiple file

commands (mput, mget, and mdelete) used in the SSL examples above. To retrieve or send multiple files at a time, use the Secure Copy (SCP) feature of SSH. Figures 2.3 and 2.4 are examples of data file submission and retrieval using SCP.

Figure 2.3 – Data File Submission Using SCP @echo off

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * rem * Example DOS batch script that will copy all files

rem * containing a certain file mask from rem * a local directory to File Exchange. rem * (via secure Copy over SSH using PSCP) rem *

rem * Usage:

rem * "putfiles (username) (password) (filemask)" rem * ex. putfiles john123 mypass *.*

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * pscp -sftp -l %1 -pw %2 -batch -q C:\upload\%3

xfile.indianamedicaid.com:/Distribution/HIPAA Transactions

(11)

@echo off

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * rem * Example DOS batch script that will get all files

rem * containing a certain file mask from a user's rem * File Exchange home directory and save them to rem * the a local directory.

rem * (via secure Copy over SSH using PSCP) rem *

rem * Usage:

rem * "getfiles (username) (password) (filemask)" rem * ex. putfiles john123 mypass *.*

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * pscp -sftp -l %1 -pw %2 -batch -q xfile.indianamedicaid.com:/Home/%1/%3 C:\download

To delete all files retrieved from File Exchange, the script must create a text file with the delete command for each file that was retrieved. Figures 2.5 and 2.6 are examples of text files and the scripts to execute the delete commands.

Figure 2.5 – Example Text File with FTP Delete Commands

del 997.124733.223.123456 del 997.152317.224.136723 del 997.144403.225.139932

Figure 2.6 – Data File Deletion Using SFTP @echo off

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * rem * Example DOS batch script that will execute FTP

rem * commands contained in a text file against files in a user's rem * File Exchange home directory.

rem * (via secure FTP over SSH using PSFTP) rem *

rem * Usage:

rem * "delfiles (username) (password) (command_file)" rem * ex. delfiles john123 mypass C:\download\delete.txt

rem * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * psftp -l %1 -pw %2 -batch -b %3 xfile.indianamedicaid.com

(12)

December 2013 12

Web interChange - HTTP over SSL

If a trading partner intends to interact with File Exchange in a manual, or ad-hoc manner, the HTTPS method using Web interChange is available. The IHCP secure website is located at

https://interchange.indianamedicaid.com .

All trading partners can log on to Web interChange using the same ID and password that is used to access File Exchange in the FTP methods listed above. This ID only has permission to access File Exchange. It cannot access the other functions of Web interChange. Accessing File Exchange via Web interChange allows each trading partner to pick up or drop off files outside of an automated script. If there is an additional file that needs to be sent to the IHCP, or if a response file is lost and needs to be retrieved again, these types of ad-hoc transmissions can be done using Web interChange.

By logging on to Web interChange, the trading partner must adhere to the password

requirements of Web interChange including changing passwords every 90 days. If it has been more than 90 since the password was changed, Web interChange prompts the trading partner to change the password. This may cause any automated FTP scripts to not connect to File Exchange. If the password is changed in Web interChange, the same change must be applied to any automated scripts to ensure uninterrupted service.

(13)

HP Delivery and Support System (DASS) -

Interactive Submission

Interactive transactions can be received from a Value Added Network (VAN) and routed through the HP/Delivery and Support System (DASS) corporate electronic transaction processing facility in Auburn Hills, MI. Transactions are then routed to the IHCP operation in Indianapolis, where responses are prepared, returned to Michigan, and ultimately returned to the requester. HP DASS System Support is managed by HP Business Exchange Services (BES). For additional information about DASS services contact:

BES HC CSC Help Desk

Daytime – 6am to 7pm central (Monday through Friday) Email: [email protected]

Phone: 972-797-9024

Connection Specifics

 Standard communication to Business Exchange Servers (BES) is over a hardware VPN tunnel utilizing TCPIP socket connections.

 VAN is responsible to maintain the connections. VAN will open/close connections as needed.

 A connection can be opened and left open for multiple request messages. Or a connection can be opened and closed for each request message.

 A connection can have only one concurrent request at a time. VAN should wait for a response or timeout on first request before sending the next request. Attempting to send multiple requests on an open connection will result in a DASS error response.

 DASS timeout is 60 seconds.

 VAN will be assigned a unique IP/Port for testing, and another unique IP/Port for production.

 The number of configured listeners will determine the max number of concurrent transactions that the VAN can submit at any one time.

Request Message Format

<Message Length><Van Header><Routing String><Terminal ID><Request Message><ETX> Example:

000628INEV20IN000001ISA*00* *00* *ZZ*IN000001 *ZZ*IHCP…

Message Length is an optional field. The field can be configured to be any length; can be ASCII characters, or binary. Value of the length field should be equal to the length of the message following the Message Length field. The value of the field does not include the length of the Message Length field itself. It is recommended that the Message Length field be used, if not used and the request message is received in multiple TCPIP packets, the request message will not be processed correctly on our system. In the examples below a 6 character ASCII Message Length field is shown.

(14)

December 2013 14

Van Header is an optional field. Field can be configured to be any length. If used will be echoed back in the response.

Routing String field is mandatory. This is a 6 character field with the current value of “INEV20”.

Terminal ID field is mandatory. A unique Terminal ID will be assigned for test and production. The format will be “IN” followed by 6 numeric characters.

Following the terminal id should be the actual request message.

An ETX character is optional; field is not needed or used by our system.

Normal Response Message Format

<Message Length><Van Header><DASS Response Code><Response Message><ETX> Example:

00063900ISA*00* *00* *ZZ*IHCP *ZZ*IN000001…

Message Length field must be the same configuration on the response message as was on the request message. Value of the Message Length field does not include the length field itself.

Van Header field will be returned in the response if sent in the request.

The next 2 characters will be the DASS Response Code. A value of “00” indicates that the Response Message was supplied by the Indiana Host system.

Following the DASS Response Code will be the actual response message from the Indiana Host.

If configuration is set to expect an ETX on the request, an ETX will be inserted at the end of the response message.

(15)

Error Response Message Format

<Message Length><Van Header><DASS Response Code><Response Message><ETX> Example:

00063926ISA*00* *00* *ZZ*IN000001 *ZZ*IHCP…

Message Length field must be the same configuration on the response message as was on the request message. Value of the Message Length field does not include the length field itself.

Van Header field will be returned in the response if sent in the request.

The next 2 characters is the DASS Response code. DASS Response codes are 10 through 99 are error codes. Most common error response codes would be due to a timeout within DASS or to the Indiana host.

In most cases the response message will contain an echo of the request message.

If configuration is set to expect an ETX on the request, an ETX will be inserted at the end of the response message.

Error Response Codes

Indicates the Most common error response codes

DASS errors from the Device Handler

 20. Unknown device id.

 21. Wrong software version.  22. Device not found in PDT.  23. Data base terminal error.

 24. Device disconnected or result of error 26 on current transaction.  25. No available slots.

 26. Received second request on same LU.  27. Bridge response timed out.

 28. Terminal not found.

DASS errors from the Bridge

 50. Pathway server timeout or nonzero reply code  51. No buffers available in Bridge

 52. Cannot route, returning request to line handler  53. Pathway server error

 54. All Pathway servers busy  55. Host response timeout

(16)

December 2013 16

DASS errors from the Host process

 40. Response from Host timed out

 42. Failed message to/from Host  43. Can't get buffer

(17)

Version CO Revision Date Revision Page Numbers

Revision Reason Completed by

2.0 March 2013 New CAQH CORE Systems 2.1 2260 Dec 2013 4, 5, 6 CAQH CORE Phase III Systems