health care claim status request and response (276/277) · .1 g. schulte lead integration architect...

All rights reserved. February 2017

HIPAA Transaction Standard Companion Guide ASC X12 005010X212A1 Health Care Claim Status

Request and Response (276/277)

Disclosure Statement This companion guide for real-time and batch 276/277 follows the CAQH CORE Phase I and Phase II guidelines.

2013 © Kaiser Foundation Health Plan of Washington CORE Claim Status Companion Guide

Kaiser Foundation Health Plan of Washington 276/277 CORE 5010 COMPANION GUIDE

2 2013 © Group Health Cooperative

All rights reserved. CORE Claim Status Companion Guide

February 2016

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.ghc.org/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.

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 claim status data electronically with Kaiser Foundation Health Plan of

Washington. Transmissions based on

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




February 2016

this Companion Guide, used in tandem with the ASC X12 276/277 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.




February 2016

TABLE OF CONTENTS

1

1.1 5

1.2 6

1.3 REFERENCES 6

1.4 6

2 GETTING

2.1 WORKING WITH OUR HEALTH 6

2.2 TRADING PARTNER 6

2.3 AND TESTING 6

3 TESTING WITH THE

4 CONNECTIVITY WITH THE

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 ......................................................................................................... 16

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

5 CONTACT INFORMATION

EDI ........................................................................................................................................................... 16

6 CONTROL

7 PAYER SPECIFIC BUSINESS RULES AND

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

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

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

8

8.1 .......................................................................................................................................19

8.2 ...............................................................................................................................................19

9 TRADING PARTNER

10 TRANSACTION SPECIFIC INFORMATION

APPENDICES

A. CHECKLIST .................................................................................................... 20 B. BUSINESS ............................................................................................................................................20

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

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

E. SFT SET UP ............................................................................................................................................ 21

F. LOSSARY .............................................................................................................................................. 21

4.1 PROCESS

4.2

4.3

8

PROCEDURES ............................... 8 9


5 2013 © Kaiser Foundation Health Plan of Washington

All rights reserved.

CORE Claim Status Companion Guide February 2016

Revision History

Date Version Description Author

11-18- 2013

2.0 New Release G. Schulte

10-24- 2014

2.1 Updated realtime response restrictions G. Schulte

02032016 2.2 Update real time response requirements G. Schulte

02-01-2017 2.3 Update Name G. Schulte Schul

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-13 1.5 Gladys Jones Health Plan IT Consultant

11/22/2013 2.0 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 276/277 transactions. This document will cover the Phase II operating rules requirements for the claim status transaction.

The 276 and 277 transactions are used in tandem: the 276 transaction is used to request the status of a health care claim(s) and the 277 to respond with the information regarding the specified claim(s). These transactions can be real-time or batch. Kaiser Foundation Health Plan of Washington supports both real-time and batch transactions; and returns detailed claim status information on the 277 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 claim status 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. acknowledgments, 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 Kaiser

Foundation Health Plan of Washington 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 Kaiser Foundation Health Plan of Washington 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 276 inquiries and receiving 277 responses for either real-time or batch to/from for Kaiser

Foundation Health Plan of Washington should contact the EDI team at [email protected].

2.2 TRADING PARTNER REGISTRATION

Trading partner registration is required in order to submit 276 requests and receive 277 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

Kaiser Foundation Health Plan of Washington 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 QA RealTime Test Request : https://dpgw-qa.ghc.org/RTCOREMimeProcessing/service/request

HTTP MIME QA Batch Test Request :

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

SOAP QA RealTime Test Request Request:

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

SOAP QA Batch Test Request 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

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 (277 or 999)

Submit confirmation to determine production readiness

Move to production upon consensus

mailto:[email protected]





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 276 inquiries are limited to one status 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 276 inquiries are limited to 99 status requests within an ST/SE grouping. A response to the batch inquiry will be provided by 7 a.m. (PST) the following business day for batches received before 9 pm (PST) the previous day. Batch requests submitted after 9 p.m. (PST) will be available by 7 a.m. (PST) 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 our EDI is located at: http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd

The WDSL definition set forth by CORE and used by our 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?WSDL

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_276_Request_005010X212

Response

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

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




Kaiser Foundation Health Plan of Washington

276/277 CORE 5010 COMPANION GUIDE

X12_277_Response_005010X212 X12_999_Response_005010X231A1

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

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 276 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_276_Request_005010X212

Response

X12_277_Response_005010X212 X12_999_Response_005010X231A1

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

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






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

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



Real-time Example:

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

X12_276_Request_005010X212 --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







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_276_Request_005010X212 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_277 X12_999_SubmissionRequest_005010X231A1

Response

X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_277_Response_005010X212 X12_Response_ConfirmReceiptReceived

Processing Mode: Processing Mode indicates Batch.

Valid value is Batch

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

ISA*00*

--XbCY--

*00* *ZZ…










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

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

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_276_Request_005010X212 X12_999_RetrievalRequest_005010X231A1 X12_005010_Request_Batch_Results_277 X12_999_SubmissionRequest_005010X231A1

Response

X12_BatchReceiptConfirmation X12_999_Response_005010X231A1 X12_277_Response_005010X212 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

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 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.


Batch 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"







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.

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--






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 claim sataus 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 277/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. All our trading partners as of December 2012 already have an account to connect to this server. 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 276/277 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

IEA02

Interchange Control – must match

Interchange Control

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 91051177

GS04 Date DT

GS05 Time TM

GS06 Group Control Number N0

GS07 Responsible Agency Code ID X






GS08

Version Identifier Code AN 005010X212

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Trailer GE GE01 Number of Transaction Sets Included

GE02 Group Control Number

ST-SE:

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Header ST ST01 Transaction Set Identifier Code ID 276

ST02 Transaction Set Control Number AN 1

ST03

Implementation Convention Reference

AN 005010 X212

Loop ID

Segment Type

Element Identifier

Element Name

Attribute

Value

Trailer

SE01 Number of Included Segments

SE02 Transaction Set Control Number

One ISA/IEA may contain more than one Functional Group (GS/GE). The functional

group must be an claim status transaction type (005010X212).

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

Not Applicable

7.3. CORE LEVEL OF CERTIFICATION

At this time Kaiser Foundation Health Plan of Washington has passed testing for CORE levels 1 and 2 certification.

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



All rights reserved. February 2016

8 ACKNOWLEDGEMENTS

8.1 REAL-TIME

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

277 response transaction indicating the requested member’s coverage or benefits (or)

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

8.2 BATCH

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

277 response transaction will be available the following day indicating the requested member’s coverage or benefits

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

9 TRADING PARTNER AGREEMENTS Trading Partner agreement is not required for claim status 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 276/277(005010X212) Health Care Claim Status Inquiry and Response Implementation Guide.

2013 © Kaiser Foundation Health Plan

of Washington

19 CORE Claim Status Companion Guide






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 (277 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 Health Real Time Transmission Example

Sample 276 Transaction

ISA*00* *00* *ZZ*YOUR ID *ZZ*910511770RT *100301*1347*!*00501*010060701*1*T*: GS*HR*YOUR ID *910511770RT *20121212*1347*10060701*X*005010X212 ST*276*010060701*005010X212 BHT*0010*13*RAM276TEST*20121212*1425 HL*1**20*1 NM1*PR*2* KAISER FOUNDATION HEALTH PLAN OF WASHINGTON *****PI*98111 HL*2*1*21*1 NM1*41*2*ABC PROVIDER SERVICES*****46*123456789 HL*3*2*19*1 NM1*1P*2* ABC PROVIDER SERVICES*****XX*188877666 HL*4*3*22*0

DMG*D8*19670203*M NM1*IL*1*CLAIMTEST*MIKE****MI*02020040 TRN*1*1220201200 REF*1K*1219015002004 AMT*T3*200.00 DTP*472*RD8*20120315-20120317 SE*16*010060701 GE*1*10060701 IEA*1*010060701






Sample 277 Transaction

ISA*00* *00* *ZZ*9810511770RT *ZZ*YOUR ID

*121228*1145*^*00501*000000001*0*T*: GS*HN*9810511770*YOUR ID*20121228*114513*1*X*005010X212 ST*277*000000001*005010X212

BHT*0010*08*010060701*20121228*114513*DG HL*1**20*1 NM1*PR*2* KAISER FOUNDATION HEALTH PLAN OF WASHINGTON *****PI*98111 HL*2*1*21*1 NM1*41*2* ABC PROVIDER SERVICES*****46*123456789 HL*3*2*19*1 NM1*1P*2* ABC PROVIDER SERVICES*****XX*188877666 HL*4*3*22*0 NM1*IL*1*CLAIMTEST*MIKE****MI*02020040 TRN*2*1220201200 STC*F1:65*20120904**200*0*20120904 REF*1K*1219015002004 REF*BLT*131 DTP*472*RD8*20120315-20120317 SE*16*000000001 GE*1*1 IEA*1*000000001

D. CHANGE SUMMARY

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

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

F. Glossary

ACRONYM

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

health care claim status request and response (276/277) · .1 g. schulte lead integration architect...

Documents