December 2013 - 005010 Page 1

HMSA

ASCX12N 835 (005010X221A1)

Health Care Claim Payment/Advice

CORE Standard Companion Guide v1.0

December 2013 - 005010 Page 2

Disclosure Statement

The information in this document is subject to change. Any revisions will be posted on our Provider E-

library website (http://www.hmsa.com/portal/provider/zav_pel.aa.HIP.500.htm).

December 2013 - 005010 Page 3

Preface

The Health Insurance Portability and Accountability Act (HIPAA) requires all covered entities to comply

with the HIPAA EDI standard transactions adopted under this Federal Regulation. The purpose of this 835

Companion Guide to the v5010 ASC X12N Technical Report Type 3 (TR3) is to clarify and specify the data

content when exchanging electronically with HMSA. This Companion Guide is intended to convey

information that is within the framework of the ASC X12N TR3s adopted for use under HIPAA. The

Companion Guide is not intended to convey information that in any way exceeds the requirements or

usages of data expressed in the TR3.

December 2013 - 005010 Page 4

Table of Contents 1 INTRODUCTION ................................................................................................................................ 5

2 GETTING STARTED ............................................................................................................................ 6

3 TESTING WITH THE PAYER ............................................................................................................... 7

4 CONNECTIVITY WITH THE PAYER/COMMUNICATIONS ................................................................... 7

5 CONTACT INFORMATION ............................................................................................................... 10

6 CONTROL SEGMENTS/ENVELOPES ................................................................................................ 11

7 PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS .................................................................... 13

8 ACKNOWLEDGMENTS .................................................................................................................... 13

9 TRADING PARTNER AGREEMENTS ................................................................................................. 13

10 TRANSACTION SPECIFIC INFORMATION ........................................................................................ 13

A. APPENDICES ....................................................................................................................................... 16

December 2013 - 005010 Page 5

1 INTRODUCTION

This application for batch 835 follows the CAQH CORE Phase III guidelines.

1.1 SCOPE Covered entities (payers, health care providers, health plans and clearinghouses) must

comply with the ASC X12N 835 (005010X221A1) TR3 for transmission of Electronic

Funds Transfer (EFT) and Electronic Remittance Advice (ERA). Our companion guide

defines CORE Business rules for 835 data content, response times, connectivity, and

system availability. This document should be used to supplement the X12N 835 TR3.

1.2 OVERVIEW In January 2012, the U.S. Department of Health & Human Services finalized the first

regulation on operating rules for eligibility and claim status transactions. Effective January

1, 2013, the Affordable Care Act (ACA) mandates adoption of the rules for Health

Insurance Portability and Accountability Act (HIPAA) electronic data interchange (EDI)

transactions. In July 2012, the second set of operating rules was published for Electronic

Funds Transfer & Electronic Remittance Advice. The compliance date is January 1, 2014.

This standard companion guide is part of the CAQH CORE Operating Rules adopted

under this Federal Regulation.

1.2.1 What is CAQH? The Council for Affordable Quality Healthcare (CAQH) is a cross-section of industry

representatives from health plans, provider networks, and Health Insurance Industry

associations. This non-profit alliance came together to provide a variety of solutions

aimed at streamlining and simplifying health care administration.

1.2.2 What is CORE? The Committee on Operating Rules for Information Exchange (CORE) was created by

CAQH to author a set of Operating Rules that would help the industry meet

requirements not currently defined in the x12 TR3. These include data content rules

and infrastructure rules.

1.2.3 What is CORE Certification?

Any entity that creates, transmits, or uses eligibility or claim status data is eligible to

become CORE-certified. CORE-certification indicates an entity has signed the CORE

Pledge and successfully completed certification testing, both of which are designed to

demonstrate an entity’s compliance with all the CORE rules. Certification is voluntary

and may be done for Phase I, II & III separately or concurrently. For more information,

go to www.caqh.org

1.3 REFERENCES

1.3.1 The ASC X12 5010 version of the HIPAA TR3s can be purchased at www.wpc-

edi.com

December 2013 - 005010 Page 6

1.3.2 HMSA’s provider portal:

http://www.hmsa.com/portal/provider/zav_pel.aa.HIP.500.htm

1.3.3 CAQH/CORE information can be found on their website:

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

1.3.4 WSDL: http://www.w3.org/TR/wsdl

1.3.5 SOAP: http://www.w3.org/TR/soap/

1.3.6: MIME Multipart: www.ietf.org/rfc/rfc2045.txt

1.3.7 CORE XML Schema: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd

1.4 ADDITIONAL INFORMATION This Companion Guide is intended for professionals who are involved in implementing EDI

solutions for health care providers, such as vendors of practice management software,

and service providers such as claims clearinghouses who send EDI on their clients’ behalf.

As such, this Companion Guide assumes a working knowledge of ASC X12, its structure

and nomenclature, and implementing or supporting different methods of connectivity. It

also assumes a working knowledge of the 835 transaction as described in the Technical

Report Type 3 (TR3).

Submitters must have a secure internet connection (HTTPS) capability to submit a

CORE 835 retrieval request and receive 835 responses.

Only batch 835 retrieval requests and responses are supported.

2. GETTING STARTED

2.1 WORKING WITH HMSA

Trading partners who wish to send electronic transactions to HMSA should contact

Electronic Transaction Services at (808) 948-6355 on Oahu or toll free at (800) 377-4672

or email edisupport@hmsa.com.

2.2 TRADING PARTNER REGISTRATION If not already submitting electronic transactions to HMSA, a trading partner will need to

complete and send back HMSA’s Electronic Trading Partner Agreement before being set

up for electronic transactions. A copy of the agreement can be found at this URL:

http://hmsa.com/portal/provider/EDI_Trading_Partner_Agreement.pdf

If the trading partner will be using a third-party to send electronic transactions to HMSA, it

must notify HMSA via Exhibit B on the agreement.

2.3 CERTIFICATION AND TESTING OVERVIEW There is no formal certification and testing for 835 HIPAA transactions.

December 2013 - 005010 Page 7

3. TESTING WITH THE PAYER

Although there is no formal testing, HMSA recommends submitting at least one request transaction to ensure connectivity and data transfer is successful. Listed below are steps to follow:

Contact Electronic Transaction Services to register X.509 digital certificate and confirm submitter id is established for batch retrieval

Create 835 retrieval request based on CAQH CORE specifications.

Submit initial request

Retrieve 835 response and review content to determine production readiness

4. CONNECTIVITY WITH THE PAYER/COMMUNICATIONS

4.1 HMSA CORE System Availability Sunday 7 p.m. – Saturday 7 p.m.

(Normally processing will be 7 x 24, however maintenance may occur between Saturday 7

p.m. (HST) and Sunday 7 p.m. (HST).

All scheduled downtimes will be posted and emergency downtimes will be noted.

4.2 Process Flows

4.2.1 Batch Pickup

1. The user application submits a batch pickup SOAP request to:

https://webservices.hmsa.com/CORE/ServiceReference.svc/batch.

2. The user application submits a batch pickup MIME request to:

https://webservices.hmsa.com/CORE.MIME/ServiceReference.svc/.

3. HMSA’s system will authenticate client credentials. If unable to

authenticate, then an HTTP 403 Forbidden response is returned.

4. HMSA’s system will validate SenderId and other elements of CORE

envelope metadata. If validation fails, HTTP 400 status response is

returned.

5. If the user is successfully authorized and envelope validated, HMSA will

deliver the response transaction(s), as appropriate for Payload Type. If no

match occurs, HTTP 400 status response is returned.

December 2013 - 005010 Page 8

CORE Compatible Application

https://webservices.hmsa.com/CORE/ServiceReference.svc/batch (SOAP)

https://webservices.hmsa.com/CORE.MIME/ServiceReference.svc/ (MIME)

Authentication HTTP 403

Send 835 Pickup Request to

Invalid

Valid

HTTP 200 and 835

Valid Envelope and

Message ?Valid

HTTP 400Invalid

4.3 Transmission Administrative Procedures 4.3.1 Structure Requirements

There is a constraint on 835 message size of 10 MB. It is strongly encouraged

that submitters retrieve 835’s frequently, as per their respective payment

cycles.

4.4 Re-Transmission Procedures If the HTTP post reply message is not received within the 60-second response

period, the user’s CORE compliant system should send a duplicate transaction

no sooner than 90 seconds after the initial attempt was sent.

If no response is received after the second attempt, the user’s CORE compliant

system should submit no more than one duplicate transaction within the next

30 minutes. If the additional attempt results in the same timeout termination,

the user’s CORE compliant system should notify the user to contact HMSA or

the information source directly to determine if system availability problems exist

or if there are known internet traffic constraints causing the delay.

4.5 Communication Protocols

4.5.1 HTTP MIME Multipart

December 2013 - 005010 Page 9

HMSA supports standard HTTP MIME messages. The MIME format used must

be that of multipart/form-data. Responses to transactions sent in this manner

will also be returned as multipart/form-data.

4.5.2 SOAP + WSDL

HMSA also supports transactions formatted according to the Simple Object

Access Protocol (SOAP) conforming to standards set forth by the Web

Services Description Language (WSDL) for XML envelope formatting,

submission, and retrieval.

4.5.2.1 SOAP XML Schema

The XML schema definition set forth by CORE is located at:

http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd

4.5.2.2 WSDL Information

The WDSL definition set forth by CORE is located at:

http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.wsdl

4.5.2.3 SOAP Version Requirements

HMSA requires that all SOAP transactions conform to SOAP Version 1.2.

4.5.3 Header Requirements

Field Accepted Values Comment

PayloadType X12_835_Request_005010X221A1

Batch Submissions

X12_005010_Response_005010X221A1

Batch Results Retrieval

ProcessingMode Batch

Batch used for either submission or pickup

TimeStamp YYYY-MM-DDTHH:MM:SSZ

See http://www.w3.org/TR/xmlschema11-2/#dateTime

SenderID HMSA Assigned EDI Submitter ID

Consistent with ISA06 of request

ReceiverID 990040115

CORERuleVersion 2.2.0

4.5.4 Error Reporting

HTTP Errors associated with connectivity, authorization, etc. will be reported at this level

HTTP 200 OK no errors

December 2013 - 005010 Page 10

HTTP 202 Accepted batch submission accepted

HTTP 400 Bad Request error with HTTP header

HTTP 403 Authentication failed

HTTP 500 Internal Server error Unexpected error during processing

Envelope

Errors regarding the structure or data included within the body of the MIME multipart message will be reported at this level in a response of type multipart/form-data.

Success no errors

PayloadTypeRequired Missing PayloadType

PayloadTypeIllegal Invalid or unsupported PayloadType

ProcessingModeRequired Missing ProcessingMode

ProcessingModeIllegal Invalid or ProcessingMode

SenderIDRequired Missing SenderID

SenderIDIllegal Invalid SenderID

ReceiverIDRequired Missing ReceiverID

ReceiverIDIllegal Invalid ReceiverID

5. CONTACT INFORMATION

5.1 EDI CUSTOMER SERVICE AND TECHNICAL ASSISTANCE

Providers and their business associates can receive assistance by contacting Electronic

Transaction Services at (808) 948-6355 on Oahu or toll free at (800) 377-4672, between 6

a.m. and 6 p.m. HST. ETS can assist providers and vendors with EDI-related issues; that

is, issues that appear to be related directly to the EDI transmission process (including

front-end rejections, missing EDI files, etc.).

We ask that vendors or clearinghouses have the following information ready for the most

efficient service:

The name and/or NPI of the provider on whose behalf the transaction was

submitted.

A detailed description of the issue, including any error messages received.

If known, the loop and/or segment in which the issue is occurring.

The HMSA assigned submitter ID/user ID.

Any related reports that were sent by HMSA.

If calling regarding claims, information on the claim(s) in question (name,

member ID, date of service, amount). If it involves a large number of claims, let

us know how many claims are affected and have one or two example claims for

the technician to check.

December 2013 - 005010 Page 11

If calling regarding remittances, information on the payment (payment date,

amount, check number, line of business, and the payee number.)

For eligibility, claim status, and other requests, the time when the request was

sent and the result.

A contact number or e-mail address should the EDI Support representative

need more information.

5.2 PROVIDER SERVICE NUMBER For issues not directly related to EDI (e.g. adjudication issues for claims), the provider can

contact Customer Relations at (808) 948-6330 or (800) 790-4672.

5.3 APPLICABLE WEBSITES/E-MAIL

More information on the EDI submission process can be found at the following web page:

http://www.hmsa.com/portal/provider/zav_pel.aa.HIP.500.htm

6. CONTROL SEGMENTS/ENVELOPES

6.1 ISA-IEA

This section describes HMSA’s use of the interchange control segments. It includes a

description of expected sender and receiver codes, authorization information, and

delimiters. Files must contain a single ISA-IEA per transaction.

ISA01 Authorization Information Qualifier “00”

ISA02 Authorization Information always spaces

ISA03 Security Information Qualifier “00”

ISA04 Security Information always spaces

ISA05 Interchange ID Qualifier (Sender) “30”

ISA06 Interchange Sender ID “990040115”

ISA07 Interchange ID Qualifier (Receiver) “ZZ”

ISA08 Interchange Receiver ID HMSA assigned submitter ID

ISA09 Interchange Date– provided by your software YYMMDD

ISA10 Interchange Time – time processed HHMM

ISA11 Interchange Repetition Separator “{“ =Left Brace for QNXT PB, Fed Plan 87 & FEP “^” =Caret for BC, MCR & QUEST

ISA12 Interchange Control Version Number “00501”

ISA13 Interchange Control Number Unique number to identify the interchange. Usually assigned by original sender’s software

ISA14 Acknowledgment requested “0” on 999 acknowledgments

ISA15 Usage Indicator “P” for Production, “T” for Test

ISA16 Component Element Separator “:”

IEA01 – Number of included functional groups

December 2013 - 005010 Page 12

IEA02 – Interchange Control Number – must match the Interchange control number in

ISA13

6.2 GS-GE

This section describes HMSA’s use of the functional group control segments. It includes a

description of expected application sender and receiver codes. Also included in this

section is a description concerning how HMSA expects functional groups to be sent and

how HMSA will send functional groups. These discussions will describe how similar

transaction sets will be packaged and HMSA’s use of functional group control numbers.

Files must contain a single GS-GE per batch or real time transaction

GS01 Functional Identifier Code “HP” (for 835 transactions)

GS02 Application Sender’s Code

“AH” = Away From Home Care “BC” = Blue Card “FE” = Federal Employee Program (FEP) “QT” = QUEST “RC” = 65 C Plus “RG” = Private Business “CLM” = more than one line of business included in the Functional Group. The subscriber number will determine which line of business the claim will be processed under.

GS03 Application Receiver’s Code

“ACC” = Accounting

GS04 Date– date processed CCYYMMDD

GS05 Time –time processed Reported as HHMMSS for PB, Fed Plan 87, MCR & QST Reported as HHMMSSDD for BC & FEP

GS06 Group Control Number Assigned by your software (usually sequential integer) 9 digit maximum with no leading zeros allowed

GS07 Responsible Agency Code “X”

GS08 Version/Release/Industry Identifier Code

“005010X221A1”

GE01 – Number of transaction sets included

GE02 – Group Control Number – Matches group control number in GS06

6.3 ST-SE

Each 835 request within a batch transaction must be wrapped in its own ST-SE segment.

Real-time inquiries must contain only one ST-SE segment. Batch transactions are limited

to 99 or less ST-SE groupings per batch file.

December 2013 - 005010 Page 13

Delimiters

Delimiter: Data Element Separator “{“ for PB, Fed Plan 87, MCR, and QUEST

“*” for BC & FEP

Delimiter: Composite Element Separator ( : ) Colon

Delimiter: Segment Terminator New Line

7. PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS

8. ACKNOWLEDGMENTS

HMSA Currently does not receive Acknowledgement files for 835 transactions.

9. TRADING PARTNER AGREEMENTS

9.2 TRADING PARTNERS

An EDI Trading Partner is defined as any HMSA customer (provider, billing service,

software vendor, employer group, financial institution, etc.) that transmits to, or receives

electronic data from HMSA.

Payers have EDI Trading Partner Agreements to ensure the integrity of the electronic

transaction process. The Trading Partner Agreement is related to the electronic exchange

of information, whether the agreement is an entity or a part of a larger agreement,

between each party to the agreement.

For example, a Trading Partner Agreement may specify among other things, the roles and

responsibilities of each party to the agreement in conducting standard transactions.

HMSA’s Trading Partner Agreement is located in our Provider E-library.

10. TRANSACTION SPECIFIC INFORMATION

This section describes how ASC X12N Technical Report Type 3 (TR3) adopted under

HIPAA will be detailed with the use of a table. The tables contain a row for each segment

that HMSA has something additional, over and above, the information in the TR3. That

information can:

1. Limit the repeat of loops, or segments

2. Limit the length of a simple data element

3. Specify a sub-set of the TR3 internal code listings

4. Clarify the use of loops, segments, composite or simple data elements

5. Any other information tied directly to a loop, segment, composite or simple data

element pertinent to trading electronically with HMSA

December 2013 - 005010 Page 14

The following table specifies the columns and suggested use of the rows for the detailed description of the transaction set companion guides. Please refer to the 5010 TR3 if not listed in the table below.

Page Loop Reference Name Codes Length Notes/Comments

123 2100 CLP Claim Payment Information

124 2100 CLP02 Codes HMSA will be using for all lines of business: 1=Processed as Primary 2=Processed as Secondary 22=Reversal of previous payment. Used to identify the ‘reversal claim’ in correcting a claim that has been paid in error. In addition to the above, Code 19 may be used for Private Business Only: 19=Processed as Primary, forwarded to additional Payer(s). Applicable to Dual Member situations only. In addition to the above, Code 4 may be used for ITS, QUEST, 65CP Only: 4=Denied (Eligibility Denials. Other denials will be reported in the Service Line Adjustment Segment CAS).

126 2100 CLP06

Claim Filing Indicator Code

HMSA will be using the following codes: 12 = Preferred Provider Organization (Blue Cross/Blue Shield Par Arrangements) 15 = Indemnity Insurance (Blue Cross/Blue Shield Non-Par Arrangements) 16 = Health Maintenance Organization (HMO) Medicare Risk HM = Health Maintenance Organization MC = Medicaid (QUEST)

127 2100 CLP07 Reference Identification

For Private Business Claim ID (up to 13 positions) For FEP Only Claim ID (up to 14 positions) For 65 C Plus & QUEST Only Claim ID (up to 15 positions) For Blue Card Only Claim ID (up to 17 positions)

129 2100 CAS Claim Adjustment

131 2100 CAS01 Claim Adjustment Group Code

CO = Contractual Obligations OA = Other Adjustments PI = Payor Initiated Reductions PR = Patient Responsibility

This code tells HMSA who (the patient or the provider) is responsible for any adjustments made

131 2100 CAS02 CAS05 CAS08 CAS11

Claim Adjustment Reason Code

Identifies the reason for the claim being adjusted. For example: 1 = deductible 2 = coinsurance

December 2013 - 005010 Page 15

CAS14 CAS17

3 = copayment Note: Your paper remittance may already contain standard code values. If so, please use the codes furnished by the primary payer. If primary payer uses proprietary reasons explaining reductions, those values will need to be mapped to standard codes for submission.

132 2100 CAS03 CAS06 CAS09 CAS12 CAS15 CAS18

Monetary Adjustment Amount

Represents the dollar amount being adjusted

132 2100 CAS04 CAS07 CAS10 CAS13 CAS16 CAS19

Represents the units of service being adjusted

137 2100 NM1 Patient Name

139 2100 NM108

Identification Code Qualifier

“MI” = Member Identification

139 2100 NM109

Identification Code

HMSA Subscriber Number – See HMSA Subscriber ID details in the Trading Partner Manual.

146 2100 NM1 Service Provider Name

Segment will not be used if Service Provider’s NPI is not available

150 2100 NM1 Crossover Carrier Name

151 2100 NM108

Identification Code Qualifier

“NI” = National Association of Insurance Commissioners (NAIC) Identification

153 2100 NM1 Corrected Priority Payer Name

154 2100 NM108 Identification Code Qualifier

PI = Payer Identification

169 2100 REF01 Reference Identification Qualifier

List CE = Class of Contract Code

170 2100 REF02 Reference Identification

For Private Business Only - Position 1 to 3 is the HMSA Coverage Code. (The same coverage code is printed on the hard copy remittance.)

186 2110 SVC Service Payment Information

186 2110 SVC01-1 Product/Service ID Qualifier

List HC = HCPCS HP = HIPPS AD = American Dental Association Codes N4 = National Drug Codes NU = National Uniform Billing Committee (NUBC) UB-04 Codes

204 2110 REF Service Identification

List

December 2013 - 005010 Page 16

204 2110 REF01 Reference Identification Qualifier

1S = Ambulatory Patient Group (APG) Number BB = Authorization Number

206 2110 REF Line Item Control Number

6R 6R = Provider Control Number

215 2110 LQ Health Care Remark Codes

HE HE = Claim Payment Remark Code

217 PLB Provider Adjustment

218 PLB02 Date Last Day of the Current Year

A. APPENDICES

1. Frequently Asked Questions

This Frequently Asked Question list is written for healthcare information technology

professionals (software vendors, clearinghouses, etc.) and providers and billers with a sufficient

technical background. Most of the information below is also explained in more detail in the

Trading Partner Manual.

What information should I give EDI Support?

When calling EDI Support as a vendor or clearinghouse, have the following information

ready for the most efficient service:

The name and/or NPI of the provider on whose behalf you are calling.

A detailed description of your issue. Include any error messages that you receive. If

you know in which loop and/or segment the issue is occurring, please provide that

information as well.

Your HMSA assigned submitter ID/user ID.

Any related reports that you may have received from HMSA.

If you are calling regarding claims, information on the claim(s) in question (name,

member ID, date of service, amount). If it involves a large number of claims, let us

know how many claims are affected and have one or two example claims for the

technician to check.

If you are calling regarding remittances, information on the payment (payment date,

amount, check number, line of business, and the payee number.)

A contact number or e-mail address that the EDI Support representative can reach you

at.

2. Change Summary

Chapter and Section Change Description Date of Change Version