835 caqh companion guide - hawaii medical service … · this companion guide is intended for...
TRANSCRIPT
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 [email protected].
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