Eligibility and Benefit Request and Response (270/271) rights reserved. February 2017 HIPAA...

All rights reserved. February 2017

HIPAA Transaction Standard Companion Guide ASC X12 005010X279A1 Eligibility and Benefit

Request and Response (270/271)

Disclosure Statement

2013 © Kaiser Foundation Health Plan of Washington CORE Eligibility Companion Guide

Kaiser Foundation Health Plan of Washington 270/271 CORE 5010 COMPANION GUIDE

2013 © Kaiser Foundation Health Plan of Washington

All rights reserved.

2 CORE Eligibility Companion Guide February 2017

This companion guide for real-time and batch 270/271 follows the CAQH CORE Phase I and Phase II guidelines.

This Companion Guide is prepared for use by trading partners affiliated with Kaiser Foundation Health Plan of Washington

This Companion Guide is to be used with, and not as a replacement for, the ASC X12N 5010 version of the HIPAA Transaction Technical Report Type 3 (TR3). The TR3’s for each transaction are available electronically from the WPC website at http://www.wpc-edi.com/.

This Companion Guide is considered a living document, and as such, the information provided herein will be subject to change. A copy of the document and any changes to the document will be posted via the Kaiser Foundation Health Plan of Washington website located at https:// kp.org/wa/provider/open/billingAndClaims/claimsProcedures/index.jhtml

Kaiser Foundation Health Plan of Washington is committed to maintaining the integrity and security of health care data in accordance with applicable laws and regulations.

http://www.wpc-edi.com/





Preface

The Health Insurance Portability and Accountability Act (HIPAA) requires all health insurance payers to comply with the Electronic Data Interchange (EDI) standards for health care as established by the Department of Health and Human Services. This Companion Guide to the v5010 ASC X12N Implementation Guide (or TR3) and associated errata, adopted under HIPAA, clarifies the data content used when exchanging eligibility data electronically with Kaiser Foundation Health Plan of Washington. Transmissions based on this Companion Guide, used in tandem with the ASC X12 270/271 and the ASC X12 999 TR3s, are compliant with both X12 syntax and the TR3. This Companion Guide is intended to convey information that is within the framework of the ASC X12 Implementation Guides adopted for use under HIPAA. The document further specifies the requirements to be used when preparing, submitting, receiving and processing electronic health care administrative data. The document supplements, but does not contradict, disagree, oppose, or otherwise modify the HIPAA Implementation Guide in a manner that will make its implementation by users to be out of compliance. Using this Companion Guide does not mean that a claim will be paid.





TABLE OF CONTENTS

1 INTRODUCTION ..................................................................................................................................... 6

1.1 OVERVIEW ........................................................................................................................................ 6

1.2 SCOPE ................................................................................................................................................. 6

1.3 REFERENCES .................................................................................................................................... 6

1.4 ADDITIONAL INFORMATION ........................................................................................................ 6

2 GETTING STARTED................................................................................................... ............................ 7

2.1 WORKING WITH OUR HEALTH PLANS ........................................................................................ 7

2.2 TRADING PARTNER REGISTRATION ........................................................................................... 7

2.3 CERTIFICATION AND TESTING OVERVIEW............................................................................... 7

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

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

4.1 PROCESS FLOW ................................................................................................................................ 8

4.2 TRANSMISSION/RE-TRANSMISSION ADMINISTRATIVE PROCEDURES .............................. 8

4.3 COMMUNICATION PROTOCOL SPECIFICATIONS.................................................................... . 9

A. SOAP: Real-time .............................................................................................................................. 9

B. MIME Multipart: Real-time.................................................................................................... .........10

C. SOAP: Batch ............................................................................................................................. ......12

D. MIME Multipart: Batch ...................................................................... ............................................13

E. HTTP Error Messages.....................................................................................................................15

F. Envelope Errors...............................................................................................................................15

G. Batch Response and Retrieval.........................................................................................................15

H. Connectivity Information to the SFTP server..................................................................................16

5 CONTACT INFORMATION .................................................................................................................16

EDI CUSTOMER SERVICE ....................................................................................................................16

6 CONTROL SEGMENTS/ENVELOPES................................................................................................16

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

7.1 SPECIFIC SERVICE CODES ............................................................................................................18

7.2 AAA CODES ............................................................................................................................... .......18

7.3. CORE LEVEL OF CERTIFICATION......................................................................................... ......18

8 ACKNOWLEDGEMENTS .....................................................................................................................18

8.1 REAL-TIME ............................................................................................ ...........................................18

8.2 BATCH ............................................................................................................................. ..................19

9 TRADING PARTNER AGREEMENTS................................................................................................19

10 TRANSACTION SPECIFIC INFORMATION ..................................................................................19

APPENDICES .............................................................................................................................................19

A. IMPLEMENTATION CHECKLIST ...................................................................................................19

B. BUSINESS SCENARIOS ....................................................................................................................20

C. TRANSMISSION EXAMPLES..........................................................................................................20

D. CHANGE SUMMARY........................................................................................................................21

E. SFT SET UP ................................................................................................................. ..........................22

F. GLOSSARY ............................................................................................................................. ................22





Revision History

Date Version Description Author

11-27-12 .1 Initial draft for review Indra Lingam

11-18-13 2.0 Revised version G. Schulte

11-24- 2014

2.1 Add response time clarifications G.Schulte

02-03-2016 2.2 Further clarification on response time G. Schulte

01-12-20-17 3.0 Name Changes G. Schulte

Reviewers

Date Version Reviewers Role & Responsibility

11-27-12 & 11-28-12

.1 G. Schulte Lead Integration Architect

Gladys Jones Health Plan IT Consultant

Jack Hempel Integration Architect

Sergio Angarita Integration Architect

Pete Schneider Integration Developer

Approvers

Date Version Approver Role & Responsibility

07-11-2013 Gladys Jones Health Plan IT Consultant








1 INTRODUCTION

1.1 OVERVIEW

The purpose of this document is to introduce and provide information about Kaiser Foundation Health Plan of Washington CAQH/CORE solution for submitting real-time and batch 270/271 transactions. This document will cover the Phase I and Phase II operating rule requirements for the eligibility transaction. The 270 and 271 Transactions are used in tandem: the 270 Transaction is used to inquire about the eligibility benefit status of a subscriber, and the 271 Transaction is returned in response to that inquiry. These transactions can be real-time or batch. Kaiser Foundation Health Plan of Washington supports both real-time and batch transactions; and returns detailed eligibility, co-payment, deductible, co-insurance, and insurance information on the 271 Response.

1.2 SCOPE

Providers, clearing houses, and other trading partners are advised to refer to the v5010 ASC X12 Implementation Guide for submitting the eligibility and benefit inquiries. This companion guide should be used to clarify and find more information about the CORE requirements and rules regarding batch and real-time transactions, i.e. acknowledgements, connectivity, response time, system availability, and data content.

1.3 REFERENCES

ASC X12 Version 5010A1 Implementation Guides: http://www.wpc-edi.com CAQH/CORE: http://www.caqh.org/benefits.php WSDL: http://www.w3.org/TR/wsdl SOAP: http://www.w3.org/TR/soap/ MIME Multipart: http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html CORE XML Schema: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd

1.4 ADDITIONAL INFORMATION

Kaiser Foundation Health Plan of Washington currently supports both batch and real-time transactions. Kaiser Foundation Health Plan of Washington has adopted the two envelope standards mandated in CORE Phase II.

1. HTTP MIME Multipart 2. SOAP + WSDL

Kaiser Foundation Health Plan of Washington has chosen the use of X.509

certificates for authentication. The external partner that wants to connect with us will issue a X.509 certificate signed by a known certificate authority (CA) i.e. VeriSign, etc. Once the certificate is issued, the external partner will provide Kaiser Foundation Health Plan of Washington with the Distinguished Name (DN) for the health plan to verify the external partner’s identity when they connect to our gateway.

http://www.wpc-edi.com/

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

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

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

http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

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





2 GETTING STARTED

2.1 WORKING WITH OUR HEALTH PLANS

Providers, billing services and clearinghouses interested in submitting 270 inquiries and receiving 271 responses for either real-time or batch to/from for both Kaiser Foundation Health Plan of Washington should contact us at [email protected].

2.2 TRADING PARTNER REGISTRATION

Trading partner registration is required in order to submit 270 requests and receive 271 responses. Please find attached in appendices the submit request form which will initiate the registration process. (Refer to Appendix F)

2.3 CERTIFICATION AND TESTING OVERVIEW

Our process requires submitting at least one test transaction to ensure data transfer is successful with connectivity using the certificate. The testing URLs are given below:

HTTP MIME RealTime QA Test Request:

https://dpgw-qa.ghc.org/RTCOREMimeProcessing/service/request

HTTP MIME Batch QA Test Request:

https://dpgw-qa.ghc.org/BTCOREMimeProcessing/service/request

SOAP RealTime QA Test Request:

https://dpgw-qa.ghc.org/RTCORESoapProcessing/service/request

SOAP Batch QA Test Request:

https://dpgw-qa.ghc.org/BTCORESoapProcessing/service/request

WSDL:

https://dpgw.ghc.org/CORESOAP/service/request?WSDL

3 TESTING WITH THE PAYER Listed below are steps to follow when testing:

• Provide the Distinguished Name for X509 Certification to Kaiser Foundation Health Plan of Washington EDI Support team

• An EDI coordinator will be assigned to work with you on the registration and

testing

• Create test transactions (preferably good and bad requests) based on

Companion Guide/Implementation Guide specifications and submit via the testing URL, either real-time or batch or both, as necessary ( Refer to Appendix C for transaction example)

• Retrieve, review, and validate the appropriate response (271 or 999)

• Submit confirmation to determine production readiness

• Move to production upon consensus

mailto:[email protected]

https://dpgw-qa.ghc.org/RTCOREMimeProcessing/service/request

https://dpgw-qa.ghc.org/BTCOREMimeProcessing/service/request

https://dpgw-qa.ghc.org/RTCORESoapProcessing/service/request

https://dpgw-qa.ghc.org/BTCORESoapProcessing/service/request






4 CONNECTIVITY WITH THE PAYER/COMMUNICATIONS

4.1 PROCESS FLOW

Process flow is layered by http process, envelope, and then business process.

Only when the inbound transmission has passed the outer layers to the business process

will a 999 and/or a 271 response be returned.

4.2 TRANSMISSION/Re-TRANSMISSION ADMINISTRATIVE PROCEDURES

Real-time 270 requests are limited to one patient request. A response to the real-time inquiry will not exceed 20 seconds on average 90% of the time for our monthly volume. If a Real time response message is not received within the 60 second response time period, the submitter’s system may send a duplicate transaction no sooner than 90 seconds after the original attempt was sent.

Batch 270 requests are limited to 99 patient requests within an ST/SE grouping. A response to the batch inquiry will be provided by 7 a.m. (PT) the following business day for batches received before 9 pm (PT) the previous day. Batch requests submitted after 9 p.m. (PT) will be available by 7 a.m. (PT) two business days following submission.

The following links below provide more information on: System Maintenance: Please refer to the respective health plan page for the most up-to-date information on system availability at: https:// kp.org/wa/provider /open/billingAndClaims/claimsProcedures/index.jhtml

System Downtime: All scheduled downtimes and the respective health plan holiday schedules will be published and emergency downtimes will be posted in the below link: https:// kp.org/wa/provider /open/billingAndClaims/claimsProcedures/index.jhtml





4.3 COMMUNICATION PROTOCOL SPECIFICATIONS

In compliance with Core rules, Kaiser Foundation Health Plan of Washington requires that all SOAP transactions conform to SOAP Version 1.2.

The XML schema definition set forth by CORE and used by Kaiser Foundation Health Plan of Washington EDI is located at: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd

The WDSL definition set forth by CORE and used by Kaiser Foundation Health Plan of Washington EDI is located at: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.wsdl

Connectivity

Mode

Transaction

Request Submission to URL

SOAP + WSDL

Secure Web

Service

Real-time Time X 12

https://dpgw.ghc.org/RTCORESoapProcessing /service/request

Secure Web

Service

Batch X12

https://dpgw.ghc.org/BTCORESoapProcessing /service/request

HTTP + MIME

Secure Web

Service

Real-time Time X12

https://dpgw.ghc.org/RTCOREMimeProcessin g/service/request

Secure Web

Service

Batch X12

https://dpgw.ghc.org/BTCOREMimeProcessing /service/request

WSDL

https://dpgw.ghc.org/CORESOAP/service/requ est?W SDL

A. SOAP: Real-time

Message Content Details:

Payload Type: Payload Type specifies the type of payload included within a request.

Valid values are: Request

X12_270_Request_005010X279A1

Response

X12_271_Response_005010X279A1 X12_999_Response_005010X231A1

Processing Mode: Processing Mode indicates Real-time processing mode. Valid value is RealTime

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

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

https://dpgw.ghc.org/RTCORESoapProcessing/service/request

https://dpgw.ghc.org/RTCORESoapProcessing/service/request

https://dpgw.ghc.org/BTCORESoapProcessing/service/request

https://dpgw.ghc.org/BTCORESoapProcessing/service/request

https://dpgw.ghc.org/RTCOREMimeProcessing/service/request



https://dpgw.ghc.org/BTCOREMimeProcessing/service/request

https://dpgw.ghc.org/BTCOREMimeProcessing/service/request








Payload ID: This is an Identifier that is used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen.

Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC) http://www.w3.org/TR/xmlschema11-2/#dateTime

Sender ID: Submitter ID/Client ID Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington

Receiver ID: Kaiser Foundation Health Plan of Washington’s Tax ID Valid value is 11 characters alphanumeric. i.e. 910511770RT

CORE Rule Version: The CORE Rule version that this envelope is using will be 2.2.0.

Payload: Payload contains compliant X12 270 request data. Payload should be encrypted using BASE 64 encode.

B. MIME Multipart: Real-time

HTTP Headers: For MIME multipart the messages should always contain Content-Type that specifies the boundary used to separate each part of the message. Example:

Content-Type: multipart/form-data; boundary=XbCY




X12_270_Request_005010X279A1

Response

X12_271_Response_005010X279A1 X12_999_Response_005010X231A1

Processing Mode: Processing Mode indicates real-time processing mode. Valid value is RealTime

Payload ID: This is an Identifier used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen.

Time Stamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC) http://www.w3.org/TR/xmlschema11-2/#dateTime

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






Sender ID: Submitter ID/Client ID. Valid value is 7 characters alphanumeric as assigned by Kaiser Foundation Health Plan of Washington.

Receiver ID: Kaiser Foundation Health Plan of Washington’s Tax ID Valid value is 11 characters alphanumeric. i.e. 910511770RT



Example:

--XbCY Content-Disposition: form-data; name="PayloadType"

X12_270_Request_005010X279A1 --XbCY Content-Disposition: form-data; name="ProcessingMode"

RealTime --XbCY Content-Disposition: form-data; name="PayloadID"

e51d4fae-7dec-11d0-a765-00a0c91e6da6 --XbCY Content-Disposition: form-data; name="TimeStamp"

2007-08-30T10:20:34Z --XbCY Content-Disposition: form-data; name="SenderID"

HOSPIX9 --XbCY Content-Disposition: form-data; name="ReceiverID"

91051170RT --XbCY Content-Disposition: form-data; name="CORERuleVersion"

2.2.0 --XbCY Content-Disposition: form-data; name="Payload"

ISA*00* *00* *ZZ… --XbCY--





C. SOAP: Batch

HTTP Headers: For MTOM the messages should always contain Content-Type that specifies among others the boundary used to separate each part of the message.

Example:

Content-Type: multipart/related; type="application/xop+xml"; start="<[email protected]>"; start-info="application/soap+xml"; action="BatchResultsAckSubmitTransaction"; boundary="---- =_Part_0_27814834.1352504024823"

In return, we will also send a Content-Type that specifies among others the boundary used to separate each part of the message.

Example:

Content-Type: multipart/related; boundary="WMBMIME1Boundaryurn_uuid_523F992ED9CE810E7F1352504025645"; start-info="application/soap+xml"; type="application/xop+xml"; start="<0.urn:uuid:[email protected]>"




X12_270_Request_005010X279A1 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_271 X12_999_SubmissionRequest_005010X231A1

Response

X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_271_Response_005010X279A1 X12_Response_ConfirmReceiptReceived

Processing Mode: Processing Mode indicates Batch.

Valid value is Batch

Payload ID: This is an Identifier that will be used to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen.

Payload Length: Defines the length of the actual X12 payload in bytes.







Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC). http://www.w3.org/TR/xmlschema11-2/#dateTime


Receiver ID: Kaiser Foundation Health Plan of Washington’s Tax ID Valid value is 9 characters numeric. i.e. 910511770


Checksum: An element used to allow receiving site to verify the integrity of the message that is sent. Algorithm is SHA-1, Encoding is Hex. Checksum must be computed only on the payload and not on the metadata.


D. MIME Multipart: Batch

HTTP Headers: For MIME multipart the messages should always contain Content-Type that specifies the boundary used to separate each part of the message. Example:

Content-Type=multipart/form-data; boundary=XbCY




X12_270_Request_005010X279A1 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_271 X12_999_SubmissionRequest_005010X231A1

Response

X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_271_Response_005010X279A1 X12_Response_ConfirmReceiptReceived

Processing Mode: Processing Mode indicates Batch. Valid value is Batch

Payload ID: This is an Identifier that you will use to uniquely identify the request submitted. Values are Alphanumeric, may contain hyphen.






Payload Length: Defines the length of the actual payload in bytes.

Timestamp: Time and Date specifying when a message is created and sent to a receiver. Valid value follows standard Universal Time (UTC). http://www.w3.org/TR/xmlschema11-2/#dateTime


Receiver ID: Kaiser Foundation Health Plan of Washington’s Tax ID Valid value is 9 characters numeric. i.e. 910511770


Checksum: An element used to allow receiving site to verify the integrity of the message that is sent. Algorithm is SHA-1, Encoding is Hex. Checksum must be computed only on the payload and not on the metadata.


Example:

--XbCY Content-Disposition: form-data; name="PayloadType"

X12_999_SubmissionRequest_005010X231A1 --XbCY Content-Disposition: form-data; name="ProcessingMode"

Batch --XbCY Content-Disposition: form-data; name="PayloadID"

f81d4fae-7dec-11d0-a765-00a0d91e6fa6 --XbCY Content-Disposition: form-data; name="PayloadLength"

10240 --XbCY Content-Disposition: form-data; name="TimeStamp"

2007-08-30T10:20:34Z --XbCY Content-Disposition: form-data; name="SenderID"

CLMLGC9 --XbCY Content-Disposition: form-data; name="ReceiverID"

910511770






--XbCY Content-Disposition: form-data; name="CORERuleVersion"

2.2.0 --XbCY Content-Disposition: form-data; name="Checksum"

6A3FE55946 --XbCY Content-Disposition: form-data; name="Payload"

SVNBKjAwKiAgICAgICAgICAqMDA=

--XbCY--

E. HTTP Error Messages

1. HTTP 200 OK – Returned when authentication is valid and request is accepted with the real-time system.

2. HTTP 202 OK – Returned when batch file submission has been accepted.

3. HTTP 400 Bad Request – Returned for incorrectly formatted HTTP headers.

4. HTTP 403 Forbidden – Returned when the user is unauthorized.

5. Server Errors – When the real-time production system is not able to process a

real-time request due to interface failures or other system unavailability, a standard 5xx series error such as HTTP 500 Internal Server Error or HTTP 503 Service Error will be returned by the application. Resubmission is recommended at a later time.

F. Envelope Errors

1. Success – Envelope was processed successfully.

2. <FieldName>Illegal – Illegal value provided for <FieldName>.

3. <FieldName>Required – The field <FieldName> is required but was not provided.

4. Version Mismatch – The version of the envelope sent is not acceptable to the receiver. If the SOAP version is not valid at the receiver, a SOAP fault is returned with this fault code.

5. Checksum Mismatched – The checksum value computed on the recipient did not

match the value that was sent in the envelope.

G. Batch Response and Retrieval

All batch requests for eligibility and batch results acknowledgment will be received by establishing a HTTP connection using CORE rules. The trading partners must submit a request for available responses. Kaiser Foundation Health Plan of Washington provides a list of 271/999 files available for pick up. Kaiser Foundation Health Plan of Washington uses an SFTP server where the files are available for pick up.





To connect to this server, the Trading Partner must request an account. For future partners, a form is available online and in Appendix E to request access to the server. The user ID assigned to log into this server is the user ID that has to be sent in the Sender ID field when submitting requests real-time or batch through the HTTP standard connection.

H. Connectivity Information to the SFTP server

Server name: sft3.ghc.org Port: 22 Folder PROD: my_inboxes/mercator/ Folder TEST: my_test_inboxes/mercator/

Maximum number of real-time and batch transactions per minute per client

Real time: 5 Batch: 1

Maximum size of Batch files: Maximum size of a file sent as an attachment to the HTTP request will be 1 MB

5 CONTACT INFORMATION EDI CUSTOMER SERVICE

For questions regarding Kaiser Foundation Health Plan of Washington 270/271 real-time and batch transmission, or this guide, please contact: EDI Support Group Monday – Friday, 8:00 AM – 4:00 PM PST Ph: (206) 901-6700 Email: [email protected]

For specific questions regarding Subscriber/Plan information, please go the web sites: https:// kp.org/wa/provider /open/billingAndClaims/claimsProcedures/index.jhtml

6 CONTROL SEGMENTS/ENVELOPES

ISA-IEA SEGMENT:

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Header ISA ISA01 Authorization Information

Qualifier

ID

0

ISA02 Authorization Information AN

ISA03 Security Information

Qualifier

ID

0






ISA04 Security Information AN

ISA05 Interchange ID Qualifier ID ZZ

ISA06 Interchange Sender ID AN

ISA07 Interchange ID Qualifier ID ZZ

ISA08(BATCH) Interchange Receiver ID AN 910511770

ISA08 (REALTIME)

Interchange Receiver ID

AN

910511770RT

ISA09 Interchange Date DT

ISA10 Interchange Time TM

ISA11 Repetition Separator ^

ISA12 Interchange Control

Version Number

ID

0501

ISA13 Interchange Control

Number

N0

ISA14 Acknowledgement

Requested

ID

0

ISA15 Usage Indicator

T-Test, P-Production

ID

T/P

ISA16 Component Element

Separator

AN :

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Trailer

IEA

IEA01 Number of Included Functional Groups

1

IEA02

Interchange Control Number – must match the

Interchange Control Number in

GS-GE SEGMENT:

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Header GS01 Functional Identifier Code ID HS

GS02 Application Sender Code AN

GS03 Application Receiver Code AN 910511770

GS04 Date DT

GS05 Time TM

GS06 Group Control Number N0

GS07 Responsible Agency Code ID X

GS08

Version Identifier Code

AN

005010X279A1

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Trailer GE GE01 Number of Transaction Sets Included 1

GE02 Group Control Number 1





ST-SE:

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Header ST ST01 Transaction Set Identifier Code ID 270

ST02 Transaction Set Control Number AN 1

ST03

Implementation Convention

Reference

AN

005010 X279A

1

Loop ID Segment

Type Element Identifier

Element Name

Attribute

Value

Trailer SE SE01 Number of Included Segments N0 1

SE02 Transaction Set Control Number AN

One ISA/IEA may contain more than one Functional Group (GS/GE). The functional group must be an eligibility transaction type (005010X279A1).

7 PAYER SPECIFIC BUSINESS RULES AND LIMITATIONS 7.1 SPECIFIC SERVICE CODES

Kaiser Foundation Health Plan of Washington EDI follows the Washington Best Practices guidelines for the Service codes. For more information please, refer to the link below: http://www.onehealthport.com/worksmart/bproverview.php

7.2 AAA CODES

Kaiser Foundation Health Plan of Washington EDI follows the Washington Best Practices guidelines for the AAA codes. For more information please, refer to the link below: http://www.onehealthport.com/worksmart/bproverview.php

7.3. CORE LEVEL OF CERTIFICATION

Kaiser Foundation Health Plan of Washington has passed certification testing for CAQH CORE Level1 and Level 2.

8 ACKNOWLEDGEMENTS 8.1 REAL-TIME

Following responses can be expected from Kaiser Foundation Health Plan of Washington EDI for a real-time 270 transaction:

• 271 response transaction indicating the requested member’s coverage or

benefits (or)

• 999 acknowledgement (for a 270 Reject) if the 270 transaction contains HIPAA compliancy errors

http://www.onehealthport.com/worksmart/bproverview.php

http://www.onehealthport.com/worksmart/bproverview.php





8.2 BATCH

Following responses can be expected from Kaiser Foundation Health Plan of Washington EDI for a batch 270 transaction:

• 271 response transaction will be available the following day indicating the

requested member’s coverage or benefits

• 999 acknowledgement within an hour if the 270 transaction contains HIPAA compliancy errors

9 TRADING PARTNER AGREEMENTS Trading Partner agreement is not required for eligibility inquiries but trading

partner registration is mandatory.

10 TRANSACTION SPECIFIC INFORMATION Kaiser Foundation Health Plan of Washington EDI follows the standard information in the ASC X12N 270/271(005010X279A1) Health Care Eligibility Benefit Inquiry and Response Implementation Guide.

Kaiser Foundation Health Plan of Washington expects all patient information in the 2000C loop at the subscriber level. Exception to this rule would be in the case of a new born child; a 2100D loop is used when the patient is a dependent of a member, and a new born child.

APPENDICES A. IMPLEMENTATION CHECKLIST

• Provide the Distinguished Name for X509 Certification to Kaiser Foundation Health

Plan of Washington

• An EDI coordinator will be assigned to work with you on the registration and

testing

• Create test transactions (preferably good and bad requests) based on Companion Guide/Implementation Guide specifications and submit via the testing link, either real-time or batch or both, as necessary ( Refer to Appendices C for transaction example)

• Retrieve, review, and validate the appropriate response (271 or 999)

• Submit confirmation to determine production readiness

• Move to production upon consensus





B. BUSINESS SCENARIOS

NA

C. TRANSMISSION EXAMPLES Kaiser Foundation Health Plan of Washington Batch Transmission Examples:

Kaiser Foundation Health Plan of Washington Sample 270 Transaction ISA*00* *00* *ZZ*YOUR ID*ZZ*910511770 *120125*1558*^*00501*000253784*0*T*:~ GS*HS* YOUR ID*910511770*20120125*1558*253784*X*005010X279A1~ ST*270*000000015*005010X279A1~ BHT*0022*13*000253784A30*20120125*1558~ HL*1**20*1~ NM1*PR*2*Kaiser Foundation Health Plan of Washington*****FI*910511770~

HL*2*1*21*1~ NM1*2B*2*ABC PROVIDER SERVICES*****FI*123456789~ HL*3*2*22*0~ NM1*IL*1*TESTFOUR*HONEYWELL****MI*02020199~ DMG*D8*19660606~ EQ*30~ SE*11*000000015~ GE*1*253784~ IEA*1*000253784~

Kaiser Foundation Health Plan of Washington Sample 271 Transaction ISA*00* *00* *ZZ*910511770 *ZZ*YOUR ID *121130*1423*^*00501*000000001*0*T*:~ GS*HB*910511770* YOUR ID*20121130*142339*1*X*005010X279A1~ ST*271*000000001*005010X279A1~ BHT*0022*11*000253784A30*20121130*142339~ HL*1**20*1~ NM1*PR*2*Kaiser Foundation Health Plan of Washington*****FI*910511770~

HL*2*1*21*1~ NM1*2B*2* ABC PROVIDER SERVICES *****FI*123456789~ HL*3*2*22*0~ NM1*IL*1*TESTFOUR*HONEYWELL****MI*02020199~ REF*18*NA*ALLIANT SELF FUNDED HSA~ REF*6P*5679600*HONEYWELL FAMILY~ N3*12401 E MARGINAL WAY~ N4*TUKWILA*WA*98168~ DMG*D8*19660606*M~ INS*Y*18~ DTP*472*D8*20121130~ DTP*346*D8*20120101~ DTP*343*D8*20121130~ EB*P****DISCLAIMER~ MSG*All benefit information provided, including eligibility status, is not a guarantee of payment. Final determination of payment will be made when the claim is adjudicated.~





EB*C*IND****22*3000*****Y~ EB*C*IND****29*555*****Y~ EB*C*FAM****22*3000*****Y~ EB*C*FAM****29*0*****Y~ EB*C*IND****22*6000*****N~ EB*C*IND****29*1591.5*****N~ EB*C*FAM****22*6000*****N~ EB*C*FAM****29*0*****N~ EB*G*IND****22*8000*****Y~ EB*G*IND****29*1973.26*****Y~ EB*G*FAM****22*8000*****Y~ EB*G*FAM****29*0*****Y~ EB*G*IND****22*16000*****N~ EB*G*IND****29*11591.5*****N~ EB*G*FAM****22*16000*****N~ EB*G*FAM****29*0*****N~ EB*R~ LS*2120~ NM1*PRP*2*ALLIANT SELF FUNDED HSA*****FI*910511770~ LE*2120~ EB*1**30^88*********Y~ EB*A**33^47^48^50^86^98ÂL^BY*****.2****Y~ EB*B**33^47^48^50^86^98ÂL^BY^BZ****0*****Y~ EB*F*IND*33***23***VS*30**W~ EB*F*IND*33***29***VS*30**W~ EB*I**35*********Y~ EB*F*IND*AL***22***VS*1**W~ DTP*348*D8*20120101~ DTP*349*D8*20121231~ EB*F*IND*AL***29***VS*1**W~ EB*U**MHÛC*********Y~ EB*1**30^88*********N~ EB*A**33^47^48^50^98^BY*****.4****N~ EB*B**33^47^48^50^86^98^BY^BZ****0*****N~ EB*I**35ÂL*********N~ EB*A**86*****.2****N~ EB*A**BZ*****1****N~ EB*U**MHÛC*********N~ SE*58*000000001~ GE*1*1~ IEA*1*000000001~

D. CHANGE SUMMARY

This is the first companion guide for eligibility from Kaiser Foundation Health Plan of Washington for CORE.





E. SFT Set up – See our web site for the current form

F. Glossary

ACRONYM DEFINITION

ASC X12N Accredited Standards Committee

CA Certificate Authority

CAQH Council for Affordable and Quality Healthcare

CORE Committee on Operating Rules for Information Exchange

DN Distinguished Name

EDI Electronic Data Interchange

HIPAA Health Insurance Portability and Accountability Act

HTTP Hypertext Transfer Protocol

MIME Message Transmission Optimization Mechanism

MTOM Multipurpose Internet Mail Extensions

SFTP Secure File Transfer Protocol

SHA-1 Secure Hash Algorithm

SOAP Simple Object Access Protocol

TR3 Technical Reports

WPC Washington Publishing Company

WSDL Web Service Definition Language

XML Extensible Markup Language

Eligibility and Benefit Request and Response (270/271) rights reserved. February 2017 HIPAA...

Documents

Transcript of Eligibility and Benefit Request and Response (270/271) rights reserved. February 2017 HIPAA...